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.
Geth MoarVM: cd809ee472 | (Stefan Seifert)++ | src/6model/containers.c
Fix possible access to fromspace in code_pair_configure_container_spec

MVM_string_ascii_decode_nt allocates, so fetch can get moved during decoding of store.		 09:05
nine dogbert11: this ^^^ fixes t/spec/S06-routine-modifiers/proxy.t. Thankfully it was a very straigt forward GC issue :) 09:06
dogbert17 nine++, so no rabbit hole this time :) 09:23
timo :+1: 10:32
i guess contspecs are only created very very early
nine There may be a rabbit hole after all. I switched back to the new-disp-nativecall branch and accidentally run that test again instead of the one I wanted to continue on. And it segfaulted. 10:53
It does so reproducibly due to a broken frame in dispatch. Now I wonder: is this something that's simply already fixed on master and my branch lacks that fix? Or is it something that my branch just unveils due to different memory layout or something like that. Or maybe even a direct regression. 10:54
dogbert17 oh, so there was a rabbit hole after all :) 11:11
nine Ok, it's not a fix in master that the branch lacks 11:16
nine According to my bisection result it's 93bfeab1ee3d62e1ba7415c3894d2c5803a947b7 "Remove old invoke protocol" 11:18
lizmat aww
nine Of all the commits in my branch, this one makes the most sense as it makes changes to frame allocation 11:19
The segfault seems to be caused by overwriting unrelated memory when promoting a frame to the heap, which could be due to miscalculating frame size 11:20
dogbert17 it's good that you found it 11:27
perhaps I should emulate timo and suggest rr :)
nine No need. That's how I know that its overwriting unrelated memory 11:34
timo nine's computer go brr 11:43
nine This is odd. jnthnwrthngtn++ recently changed it so a frame's work registeres are allocated on the callstack, basically as part of the frame. Yet MVM_frame_move_to_heap does not deal with work registers at all. The work pointer is just copied from the frame on the callstack and will still point into the callstack. 11:46
Now this looks very much like a simple oversight and could cause such interesting issues. But it also sounds like it would wreak havoc long before my branch. 11:47
Ah, I may just misunderstand things. Apparently the original callstack entry of the frame will remain 11:50
timo maybe this is about whether we'll run code in there again?
work is not accessible to inner frames and such, only the lexicals
nine Oh what a perfect way to waste some time. Pro tip: after switching branches touching MoarVM headers, recompile rakudo. 12:52
nine can't wait to see extops gone
timo d'oh 12:57
lizmat And yet another Rakudo Weekly news hits the Net: rakudoweekly.blog/2021/11/01/2021-...0-rakoons/ 13:38
Geth MoarVM: 0821570aaa | (Stefan Seifert)++ | src/6model/containers.c
Avoid MVMROOT by better sequencing of the code

zhuomingliang++ for suggesting this much better version of the GC issue fix
jnthnwrthngtn nine: The lifetime of ->work is always that of the dynamic scope of the frame, which is precisely the lifetime of the callstack record, so there's no need to move that (unlike the environment, which can - in a promoted frame - outlive the dynamic scope) 13:59
This is very much by design, not an oversight.
nine At least that motivated me to have a look at the remaining extops. Couldn't RAKUDO_FIRST_FLAG easily be replaced with a state var? 14:11
jnthnwrthngtn Cheaper in terms of keeping the loop body inlinable would be a secret lexical in the outer scope. 14:12
(We can't inline things with state vars, I'm not really hurrying to implement that, and it's probably easier to implement it as a lexical in the scope where the loop appears anyway)
timo it can't be a local from the start? 14:17
oh, only after inlining, of course
dogbert17 Already set resume init args for this dispatcher 17:55
in block at t/spec/S02-types/range.t line 424
in sub subtest at /home/dogbert/repos/rakudo/lib/Test.rakumod (Test) line 437
this pops up when running with a (very) small nursery and MVM_SPESH_BLOCKING=1 plus MVM_SPESH_NODELAY=1 17:56
timo the --ll-exception here could be interesting 17:57
dogbert17 timo: gist.github.com/dogbert17/9c648c7e...c6e046b573 18:01
timo and dump_bytecode from inside that dispatcher as well
dogbert17 aha
timo did we get any further for the "need to use tracked capture" one from the other day? that was you with a small nursery as well wasn't it? 18:02
dogbert17 timo: gist updated 18:05
the other bug didn't want to show itself when nine tried to repro :( 18:06
timo ok, so the only way to reach that error message is through the syscall dispatcher-set-resume-init-args 18:18
and there's only one call to that in our dumped bytecode
and this is the boot-resume-caller dispatcher i assume 18:20
i think my local v6c.nqp from BOOTSTRAP doesn't match the line numbers supplied 18:21
ok, i'm still on my branch so no big surprise
what's that line on your machine there? 18:22
might be interesting to see the contents of the record->rec.resume_inits 18:30
dogbert17 6481 # Initialization of a non-trivial dispatch. Receives a dispatch resumption 18:55
6482 # kind, which is zero if we're not resuming.
6483 -> $capture {
6484 # Extract and guard on the kind (first argument).
running it under gdb led to a 'MoarVM panic: Adding pointer 0x555555686208 to past fromspace to GC worklist' 19:01
(gdb) p *record->rec.resume_inits 19:06
$3 = {disp = 0x555556c9c698, capture = 0x55555555bc18}
I updated the gist with some info about the panic, perhaps nine++ can make something of that 19:12
timo so perhaps we're not marking everything in these records 19:45
timo how many resume inits are in there? you'll want to print the entire record->rec actually, forgot how that works 20:21
dogbert17 (gdb) p record->rec 20:37
$7 = {initial_capture = {capture = 0x55555555b2b0, transformation = MVMDispProgramRecordingInitial, index = 21845, value_index = 1516444472, captures = 0x55555a6a3490, captures_num = 1, captures_alloc = 8},
resume_kind = MVMDispProgramRecordingResumeCaller, inline_cache_size = 1, resumptions = 0x55555a69d6d0, resumptions_num = 3, resumptions_alloc = 4, values = 0x55555a6a4ac0, values_num = 26,
values_alloc = 34, resume_inits = 0x55555a69c7b0, resume_inits_num = 1, resume_inits_alloc = 4, outcome_value = 1516458416, outcome_capture = 0x0, bind_failure_resumption_flag = 1484418240,
bind_success_resumption_flag = 21845, map_bind_outcome_to_resumption = MVMDispProgramRecordingBindControlNone, do_not_install = 0 '\000'}
japhb What's with all the hex 5's? 20:41
timo ok so there's just the one resume_inits, the one you already posted, with the disp and the capture 20:42
japhb (BTW, I'm not actually just being silly, strings of 0101 are often used as sentinels, so it is really weird seeing it so much here.) 20:43
timo dogbert17 could give us the output of /proc/$pid/maps (or i guess gdb probably has a command that does something similar) where these address ranges live 20:44
dogbert17 timo: gist updated 20:53
timo ok the 5s are harmless then
japhb Weird, but yeah, I suppose so. 21:54

Powered by Cro and the Raku® Programming Language.

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

Thank you!