github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:07 AlexDani` joined 01:08 AlexDaniel left 02:20 elcaro_ is now known as elcaro 03:11 MasterDuke left 03:55 [Coke]_ joined, [Coke]_ left, [Coke]_ joined 03:57 Geth left, Geth joined 03:58 [Coke] left 04:26 [Coke]_ left 04:35 [Coke] joined, [Coke] left, [Coke] joined 05:28 squashable6 left 05:31 squashable6 joined
nwc10 good *, #moarvm 06:18
06:44 domidumont joined 06:53 Altai-man joined 07:19 sena_kun joined 07:21 Altai-man left 08:02 zakharyas joined 08:12 domidumont left 08:16 domidumont joined
jnthn o/ 09:52
nwc10 \o 10:02
10:07 Kaiepi left 10:09 Kaiepi joined 11:18 Kaiepi left, Altai-man joined 11:21 sena_kun left 11:26 Kaiepi joined 11:31 zakharyas left 11:37 Kaiepi left 11:39 leont joined 12:32 zakharyas joined 12:48 dogbert17 left 13:10 brrt joined 13:41 mst joined, ChanServ sets mode: +o mst 15:19 sena_kun joined 15:21 Altai-man left 15:56 Kaiepi joined 16:04 Kaiepi left 17:03 MasterDuke joined 17:14 brrt left 17:42 zakharyas left 18:30 Kaiepi joined
MasterDuke ok. anyone up for helping me (fair warning it's gonna be a heavy lift on your end) figure out what to MVM_ASSIGN_REF to get github.com/MoarVM/MoarVM/pull/1344 not segfaulting when building nqp? 19:18
19:18 Altai-man joined 19:21 sena_kun left 19:25 Altai-man left
MasterDuke heh. i have an MVM_ASSIGN_REF expression that compiles, but same segv when building nqp 19:42
oh, now i have something that gets farther in the nqp build 19:44
an actual `Try to enter NULL jitcode` exception instead of a segv 19:45
the moarvm backtrace is not helpful 19:46
does this look close? `for (MVMuint32 i = 0; i < spesh->body.num_spesh_candidates; i++) MVM_ASSIGN_REF(tc, &(spesh->common.header), spesh->body.spesh_candidates[i], new_candidate_list[i]);` 20:18
jnthn Is it the correct way around? 20:19
I'd have thought you'd be assigning into the new candidate list?
But if this is just copying the existing candidates into the new candidate list then it's not needed at all, I think, since those were already pointed to by the spesh holding object 20:20
MasterDuke dunno, that's my interpretation of colabti.org/irclogger/irclogger_lo...09-08#l144
jnthn You'll need to do it with the new candidate, just not the existing ones 20:21
Is the PR up to date? I can glance it
timotimo i thought it was necessary so that the pointers in the array also get updated if necessary
nine MasterDuke: frames have a spesh_cand pointer. Where is that put onto the GC's worklist?
MasterDuke it doesn't have the MVM_ASSIGN_REF i was just experimenting wiht 20:22
up to date otherwise
nine: i don't think it is... 20:23
there's this github.com/MoarVM/MoarVM/pull/1344...89ff1d2R33 20:24
nine Have a look at MVM_gc_root_add_frame_roots_to_worklist 20:25
jnthn MasterDuke: This line:
new_candidate_list[spesh->body.num_spesh_candidates] = candidate;
Is the one that needs the MVM_ASSIGN_REF 20:26
MasterDuke i just changed to only having this: `MVM_ASSIGN_REF(tc, &(spesh->common.header), spesh->body.spesh_candidates[spesh->body.num_spesh_candidates], new_candidate_list[spesh->body.num_spesh_candidates]);`
same segv
but looking at MVM_gc_root_add_frame_roots_to_worklist now 20:27
adding `MVM_gc_worklist_add(tc, worklist, &cur_frame->spesh_cand);` here github.com/MoarVM/MoarVM/blob/mast...ots.c#L419 didn't change anything 20:29
jnthn MVM_ASSIGN_REF(tc, &(spesh->common.header), new_candidate_list[spesh->body.num_spesh_candidates], candidate); 20:30
Is probably fine
MasterDuke ah. the addition to MVM_gc_root_add_frame_roots_to_worklist plus that change to the MVM_ASSIGN_REF gets farther 20:32
MoarVM panic: Internal error: zeroed target thread ID in work pas
20:32 domidumont left 20:33 brrt joined, domidumont joined, domidumont left
jnthn Do you have the MVM_GC_DEBUG turned on? 20:34
MasterDuke oh! it actually finishes if i remove the '-j12' from my make call
timotimo nqp can't be compiled with that many things in parallel :D 20:35
MasterDuke which i've never had to do before
jnthn 'cus often it catches those zeroed target corruptions earlier - at the point something adds to the worilist
haha...worklist :)
Though we are woried about it :P
MasterDuke jnthn: no, it's currently 0, i'll try again with it set to 1
jnthn OK. With luck it'll panic at the point where the thing is added, which could be informative
MasterDuke i am building moarvm with `--debug=3 --optimize=0` 20:36
jnthn Good; that means you'll get a useful stack trace out of gdb when (if) it panics :) 20:37
afk for a bit
MasterDuke of course now nqp builds even with -j12... 20:38
but rakudo panics 20:41
at github.com/MoarVM/MoarVM/pull/1344...43a02d7R45 `for (i = 0; i < candidate->num_spesh_slots; i++) { MVM_gc_worklist_add(tc, worklist, &(candidate->spesh_slots[i])); }` 20:42
hm. `num_spesh_slots = 4152756840` 20:44
timotimo is that fefefefefe? 20:46
20:47 AlexDani` left
MasterDuke m: say 0xfefefefefe 20:48
camelia 1095199817470
MasterDuke m: say 0xfefefefe
camelia 4278124286
timotimo m: say 0xfe, 0xfefe, 0xfefefe, 0xfefefefe, 0xfefefefefe
camelia 254652781671142242781242861095199817470
timotimo m: say (0xfe, 0xfefe, 0xfefefe, 0xfefefefe, 0xfefefefefe).join(", ")
camelia 254, 65278, 16711422, 4278124286, 1095199817470
timotimo ok, not quite, but almost
m: say 4152756840.base(16)
camelia F7860A68
timotimo certainly not a correct value for the amount of spesh slots 20:49
MasterDuke seems one, maybe two more than expected, yeah 20:50
brrt timotimo: what's the significance of fefefefe 20:52
timotimo in one of the gc debug modes we overwrite the old nursery with that using memset 20:53
and maybe other things we free?
brrt that makes sense 20:55
20:58 MasterDuke left 21:13 MasterDuke joined
MasterDuke PR updated with current state. it builds nqp, but panics when building rakudo 21:17
21:26 mst left 22:01 [Coke] left 22:04 [Coke] joined, [Coke] left, [Coke] joined 22:29 brrt left 23:43 colomon__ left 23:45 colomon joined 23:46 colomon left 23:57 mst joined, ChanServ sets mode: +o mst

Powered by Cro and the Raku® Programming Language.

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

Thank you!