nwc10 .tell jnthn I think that if an MVMCompUnitBody gets promoted to the 2nd gen, it can end up with elements of scs[] still being in the nursery, and hence not properly marked at the next nursery-only sweep 20:34
mmm, that didn't work.
FROGGS preflex: tell nwc10 That should do. 20:35
ahh, no preflex here :/ 20:36
nwc10 test (please ignore)
FROGGS preflex is in #perl6
nwc10 and via privmesg as tell
FROGGS k 20:37
nwc10 anyway, I have a stinker of a GC bug where the value 0x6 ends up as a pointer in scs[4] for a frame, which crashes gc_mark in MVMCompUnit
and it seems to be a pointer to memory in tospace which has become re-used as part of an array 20:38
and then that bit of memory gets misinterpreted as the forwarder address during a GC sweep, so somethign else gets updated
er, scs[4] gets update because the sweeper thinks that it's pointing to fromspace, and the fromspace has a forwarder to 0x6 20:39
so I think that an even number of GC runs have happened (maybe just 2)
during which whatever scs[4] was pointing to got into fromspace, but scs[4] never got updated. Or the thing pointed to was never marked 20:40
oh, if all else fails, let's RTFM
nwc10 makes RTFMing noises
FROGGS I am not sure what the solution is... the addresses of scs[4] need either temp_push'd or ASSIGN_REF'd I guess 20:42
timotimo don't we allocate a whole new tospace every time? 21:57
(maybe we should)
FROGGS no, we allocate that fromspace/tospace area just once 21:58
we could change that for debugging reasons perhaps 21: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!