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.
lizmat PSA: if you like Geth to announce github events again, change the server name in the webhook to webhooks.liz.nl 13:52
Geth MoarVM/new-disp: a7981b98bb | (Jonathan Worthington)++ | src/6model/reprs/MVMCapture.c
Fix missing GC rooting in capture transforms
 14:17
MoarVM/new-disp: 268c2badc5 | (Jonathan Worthington)++ | src/disp/boot.c
Fix use of moved collectables in lang* dispatchers
jnthnwrthngtn yay, it works
That was a replay from a push yesterday
Geth MoarVM/new-disp: d28b689f33 | (Jonathan Worthington)++ | src/core/callsite.c
Consistently use named args count function
 14:20
MoarVM/new-disp: cbd493b0a5 | (Jonathan Worthington)++ | 3 files
GC mark interned callsites

We got away with this thanks to compunits only rarely getting collected, but now that we produce callsites regularly as a result of flattening that we then go on to intern, we really should do it.
jnthnwrthngtn lizmat++ # Geth resurrection
Sigh, why do I suddenly get "ASan runtime does not come first in initial library list" today when it worked fine yesterday... 14:27
Nicholas jnthnwrthngtn: that now gets me: 14:28
MoarVM panic: Zeroed owner in item added to GC worklist
somewhere in the NQP build
jnthnwrthngtn Hm, but not the ASAN panic? 14:30
nine jnthnwrthngtn: nqp built on a MoarVM with ASAN?
jnthnwrthngtn Yes
Turns out that nuking my install directory worked
I've no idea why
But yay working ASAN again
Nicholas that's not an ASAN panic. That's one of the #defines 14:31
jnthnwrthngtn Nicholas: Does it happen at the end of the build when buliding gen/moar/stage2/NQPP5QRegex.nqp
Nicholas Last lines where: 14:32
were:
+++ Installing MOAR stage 2 files locally
+++ Compiling NQPP5QRegex.moarvm
jnthnwrthngtn Nicholas: I know, but with FSA_DEBUG on then ASAN I think should trip before it gets there. Recreating that now
Nicholas MoarVM panic: Zeroed owner in item added to GC worklist
Aborted
jnthnwrthngtn Yeah, ok. I don't get zeroed owner, but bogus one, but the same kinda issue 14:33
grr, it doesn't 14:34
ahh, I think a) I found it, b) I know why at some point it looked like the same use after free bug I was hunting yesterday 14:43
Sigh, no. 15:14
Geth MoarVM/new-disp: 9668dfc167 | (Jonathan Worthington)++ | src/core/callsite.c
Avoid repeated dereferencing in intern cleanup
 15:37
MoarVM/new-disp: 39ff70c663 | (Jonathan Worthington)++ | src/disp/program.c
Form capture before making dispatch record

Otherwise the allocation can cause us to see things in a state of incomplete setup, which can cause us to go doing incorrect marking.
jnthnwrthngtn Trying to track it down with the "GC on every allocation" option showed up the issue fixed in the second commit 15:42
However, dropping back to another debug level gets me back to the very same failure mode I had before 15:43
nine jnthnwrthngtn: have you ever tried the gcc plugin for finding GC issues? 15:46
jnthnwrthngtn nine: Not yet 15:48
It's static analysis?
nine yes
It takes a bit of effort to get up and running, so it's usually not worth it for finding a single issue. But with large amounts of new code it could pay off 15:50
jnthnwrthngtn Yeah, should certainly throw it at this. I'm still not quite sure if I'm looking at a straight GC issue; nothing trips in the right places 16:00
nine jnthnwrthngtn: I've ran it. Maybe worth a look: gist.github.com/niner/d2afe30b8246...6d14cb26b9 16:05
Geth MoarVM/new-disp: 5ce86d7a60 | (Jonathan Worthington)++ | src/disp/boot.c
Fix a missing MVMROOT found by static analysis

  nine++		 16:22
jnthnwrthngtn nine: That's legit, I think. Hopefully the commit quiets it. Sadly, not the one I'm hunting, it seems. 16:23
Fixing lots of things at least but sigh, this one is taking a while to hunt 16:26
nine Missing root for `result` in try_update_cache_entry (tc, entry_ptr, &unlinked_getlexstatic, _6); at src/disp/inline_cache.c:31 used in D.23824 = result; at src/disp/inline_cache.c:33 16:28
Missing root for `id` in _4 = MVM_disp_program_run (tc, dp, record); at src/disp/inline_cache.c:133 used in disp = MVM_disp_registry_find (tc, id); at src/disp/inline_cache.c:147
jnthnwrthngtn Hm, is that newly added in what you sent before, or? 16:31
huh, disp_registery_find can allocate?
oh, maybe that's not what it is saying 16:33
nine I'm trying to re-generate the list of functions that can alloc. Sadly my past self sucked at giving me hints about how I came up with the original one... 16:34
jnthnwrthngtn: no, it means that disp_program_run can allocate and the variable is used later on in that disp_registry_find call 16:35
The MVM_ROOT needs to be around the MVM_disp_program_run call
jnthnwrthngtn Ah, right 16:37
In theory it can't ever allocate unless it reaches a dispatch terminal
And if it reaches one of those it'll be successful
Still, better safe than sorry 16:38
nine groceries & 16:41
Geth MoarVM/new-disp: 4dd0c3055a | (Jonathan Worthington)++ | src/disp/inline_cache.c
Ensure we root in case dispatch program allocates

In theory it should not in any paths that don't lead to a successful dispatch outcome, but that feels like playing with fire, so add the roots anyway.		 16:45
nine Missing root for `returner` in caller = MVM_callstack_unwind_frame (tc, _22, &thunked); at src/core/frame.c:1058 used in returner->caller = 0B; at src/core/frame.c:1060 16:48
Missing root for `frame` in _55 = remove_one_frame (tc, 1); at src/core/frame.c:1297 used in frame.247_57 = frame; at src/core/frame.c:1234 16:49
Missing root for `return_value` in _55 = remove_one_frame (tc, 1); at src/core/frame.c:1297 used in return_value.233_21 = return_value; at src/core/frame.c:1246
Geth MoarVM/new-disp: 4176a7f98c | (Jonathan Worthington)++ | src/core/frame.c
Fix two more missing GC rootings

Frame unwinding can now potentially lead to allocations if, for example, there is lazy deopt.		 21:35

Powered by Cro and the Raku® Programming Language.

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

Thank you!