Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
00:07 reportable6 left 00:08 reportable6 joined 00:46 bloatable6 joined, releasable6 joined 00:47 bisectable6 joined, coverable6 joined, linkable6 joined 00:48 committable6 joined, shareable6 joined 01:25 vrurg_ joined 01:27 vrurg left 01:44 frost joined 01:45 ugexe left 01:46 tellable6 joined 02:08 ugexe joined 02:10 ugexe left 02:11 ugexe joined 02:46 greppable6 joined 03:47 statisfiable6 joined, benchable6 joined 04:47 evalable6 left, linkable6 left 06:04 releasable6 left, benchable6 left, greppable6 left, statisfiable6 left, shareable6 left, bloatable6 left, unicodable6 left, reportable6 left, notable6 left, nativecallable6 left, coverable6 left, committable6 left, sourceable6 left, squashable6 left, bisectable6 left, quotable6 left 06:05 bloatable6 joined, committable6 joined, benchable6 joined, squashable6 joined, nativecallable6 joined 06:06 sourceable6 joined, bisectable6 joined, reportable6 joined, quotable6 joined, coverable6 joined 06:07 shareable6 joined, notable6 joined, releasable6 joined 07:05 statisfiable6 joined 07:08 unicodable6 joined 07:49 evalable6 joined
nine LibXML's 90-threads.t yields quite unexpected results. It suffers from at least 2 problems, both rather long standing: MVM_nativecall_dispatch inherited some unsafe access to a possibly outdated body from MVM_nativecall_invoke (i.e. a GC issue). And CompUnit::Repository::Filesystem's cache is not thread safe 08:23
CompUnit::Repository::Installation suffers from the same problem. 08:24
Geth MoarVM: f4aa22ad03 | (Stefan Seifert)++ | src/core/nativecall_dyncall.c
Fix possible access to fromspace in native calls

Since the native callsite can be moved by the GC, the body pointer can become outdated. That's why we have local copies of all the body fields we need for calling and processing return values. However in quite a few places we still accessed the (by then outdated) body pointer instead of the local variables.
Fix by replacing all unsafe access to the NC body with using those local copies.		 09:01
09:06 greppable6 joined 09:17 frost left 09:18 frost joined 09:49 linkable6 joined 09:51 Nicholas joined 11:34 Altai-man joined 12:04 squashable6 left 12:06 squashable6 joined 12:08 reportable6 left 12:10 reportable6 joined 13:31 [Coke] left 13:34 [Coke] joined 14:11 frost left 17:21 evalable6 left, linkable6 left 18:07 reportable6 left 18:09 reportable6 joined 18:15 Altai-man left 18:21 linkable6 joined
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2021/12/20/2021-...ransiting/ 18:59
Geth MoarVM: niner++ created pull request #1624:
Fix possible access to fromspace when autoboxing return values		 20:14
nine Just noticed that I forgot to create a PR from this branch 20:15
20:17 CaCode joined
MasterDuke nine: is github.com/MoarVM/MoarVM/blob/mast...ffi.c#L673 safe? 20:19
nine MasterDuke: notable6: 20:20
MasterDuke: no! And no idea why I missed that
20:20 patrickb joined 20:21 evalable6 joined
MasterDuke lizmat++ btw, the"optimised some string to integer conversions" in the weeks should be "integer to string" 20:23
lizmat MasterDuke++ # fixed 20:24
MasterDuke nine: and i assume you've already seen dev.azure.com/MoarVM/MoarVM/_build...1ceda7bc7c ? 20:25
lizmat++ it's going to take me a while to get through this weekly again, they seem to be growing in size
nine Actually I haven't
lizmat MasterDuke: yeah, it's becoming a major time sink :-) 20:26
MasterDuke incredibly valuable, hope they aren't too much of a burden 20:27
sort of changing topics, but does anyone have any code to benchmark something like "producer/consumer situations where memory is allocated on one thread and freed on another (anything that heavily uses the ThreadPool probably does)"? re github.com/MoarVM/MoarVM/issues/1623 20:31
timo: do your sdl examples do this?
Geth MoarVM/fix_autoboxing_gc_issue: f0e4b08c09 | (Stefan Seifert)++ | src/core/args.c
Fix possible access to fromspace when autoboxing return values

If the target frame (e.g. tc->cur_frame) is a heap frame that lives in the nursery, the return value is a native value (e.g. return_i or a native call), the caller expects an object and boxing happens to trigger a GC run, the target frame could be moved before we dereference the target pointer to get the return_value register. This would lead to a segfault with GC_DEBUG 3. ... (5 more lines)		 20:32
20:33 japhb left
nine MasterDuke: at least I now learned about this quirk of the C grammar 20:33
MasterDuke heh. nine++ on a roll 20:38
lizmat: do you regularly check LWN for raku mentions? it was mentioned a week or so ago in some comments and i don't remember seeing it linked in any of the weeklies 20:42
lwn.net/Articles/878451/ 20:43
lizmat well, Google in that case doesn't pick up on that either then
also, that comment doesn't even show up in lwn.net/Search/DoSearch either 20:45
MasterDuke huh. i just noticed because i had read the article+comments
21:09 MasterDuke left 21:21 MasterDuke joined 21:24 CaCode left
MasterDuke just compiled CORE.c and ran a spectest with mimalloc-(debug|secure) + MIMALLOC_SHOW_STATS=1 and no errors printed, so that's good 21:58
22:08 CaCode joined
dogbert17 there seems to be a SEGV hiding in t/02-rakudo/repl.t 22:15
The spawned command '/home/dogbert/repos/rakudo/rakudo-m' exited unsuccessfully (exit code: 0, signal: 11) 22:16
in sub is-run-repl at /home/dogbert/repos/rakudo/t/packages/Test/Helpers.pm6 (Test::Helpers) line 62 22:17
in sub is-run-repl at /home/dogbert/repos/rakudo/t/packages/Test/Helpers.pm6 (Test::Helpers) line 53
in block <unit> at t/02-rakudo/repl.t
MasterDuke i've seen that one flap before, never caught it in anything 22:21
22:39 CaCode_ joined 22:42 CaCode left 22:46 patrickb left
dogbert17 MasterDuke: the SEGV occured here, github.com/MoarVM/MoarVM/blob/mast...erp.c#L259 23:39
MasterDuke wonder if that's just memory corruption of the bytecode. do you have a gdb backtrace? 23:42
dogbert17 (gdb) bt 23:44
#0 0x00007f9659cb1d6e in MVM_interp_run (tc=0x5632246e8e30, initial_invoke=0x0, invoke_data=0x0, outer_runloop=0xffff) at src/core/interp.c:259
#1 0x000056322343f7fb in main (argc=7, argv=0x7ffe81e46cb8) at src/main.c:307
MasterDuke heh, don't think i've ever seen one with only two frames before 23:46
dogbert17 yeah, it's a bit on the thin side :) 23:47
the JIT seems to be innocent 23:59

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!