[00:00] yeah, added a print if it's passed in, only happens once and then the segv [00:01] in the very first file of the nqp build [00:02] Can you breakpoint where we emit the sp_invoke_* in optimize.c and see if the spesh cand looks legit when we poke it into the slot? [00:03] This all looks annoyingly simple/correct :) [00:03] Which means when we figure out I'll feel silly [00:03] heh, yep [00:04] (gdb) p *cands_and_arg_guards->spesh_candidates[spesh_cand] [00:04] $1 = {common = {header = {sc_forward_u = {forwarder = 0x0, sc = {sc_idx = 0, idx = 0}, st = 0x0}, owner = 3, flags1 = 0 '\000', flags2 = 32 ' ', size = 216}, st = 0x55555558fc40}, body = {cs = 0x7ffff7deb6e0 , [00:04]     type_tuple = 0x7ffff00063b0, discarded = 0 '\000', bytecode_size = 2180, bytecode = 0x7ffff00e93e0 , handlers = 0x7ffff003c5f0, spesh_slots = 0x7ffff00e2f60, num_spesh_slots = 38, num_deopts = 96, [00:04]     deopts = 0x7ffff0051d00, deopt_count = 0, deopt_named_used_bit_field = 0, deopt_pea = {materialize_info = 0x0, materialize_info_num = 0, materialize_info_alloc = 0, deopt_point = 0x0, deopt_point_num = 0, deopt_point_alloc = 0}, [00:04]     num_inlines = 3, inlines = 0x7ffff00e0d60, local_types = 0x7ffff00e0e10, lexical_types = 0x7ffff0002230, num_locals = 70, num_lexicals = 0, work_size = 640, env_size = 0, num_handlers = 6, jitcode = 0x0, [00:04]     deopt_usage_info = 0x7ffff00ea9e0}} [00:05] that looks better [00:05] btw, the segv is here https://github.com/MoarVM/MoarVM/blob/master/src/core/frame.c#L300 [00:15] huh. the spesh_cand_slot was 12 [00:16] i then put a breakpoint in interp.c's sp_fastinvoke_o [00:16] right before the MVM_frame_invoke call [00:17] and continued [00:17] but GET_UI16(cur_op, 4) was 18 [00:19] nm, that was after cur_op += 6; [00:20] GET_UI16(cur_op, 4) when getting the spesh slot was in fact 12 [00:24] *** dogbert17 joined [00:28] *** dogbert12 left [00:31] Hm, odd [00:31] I should sleep, 'night o/ [00:31] same here [01:26] *** MasterDuke left [03:53] *** quotable6 left [03:53] *** greppable6 left [03:53] *** notable6 left [03:53] *** bloatable6 left [03:53] *** committable6 left [03:53] *** bisectable6 left [03:53] *** linkable6 left [03:53] *** nativecallable6 left [03:53] *** statisfiable6 left [03:53] *** coverable6 left [03:53] *** unicodable6 left [03:53] *** shareable6 left [03:53] *** evalable6 left [03:53] *** benchable6 left [03:53] *** squashable6 left [03:53] *** releasable6 left [03:53] *** tellable6 left [03:53] *** sourceable6 left [03:54] *** evalable6 joined [03:54] *** committable6 joined [03:54] *** nativecallable6 joined [03:54] *** releasable6 joined [03:54] *** bisectable6 joined [03:54] *** sourceable6 joined [03:54] *** tellable6 joined [03:54] *** bloatable6 joined [03:55] *** linkable6 joined [03:55] *** coverable6 joined [03:55] *** greppable6 joined [03:55] *** shareable6 joined [03:56] *** benchable6 joined [03:56] *** squashable6 joined [03:56] *** notable6 joined [03:56] *** statisfiable6 joined [03:56] *** unicodable6 joined [03:56] *** quotable6 joined [04:56] *** coverable6 left [04:56] *** quotable6 left [04:56] *** sourceable6 left [04:56] *** unicodable6 left [04:56] *** greppable6 left [04:56] *** bloatable6 left [04:56] *** nativecallable6 left [04:56] *** committable6 left [04:56] *** benchable6 left [04:56] *** notable6 left [04:56] *** statisfiable6 left [04:56] *** tellable6 left [04:56] *** squashable6 left [04:56] *** bisectable6 left [04:56] *** releasable6 left [04:56] *** shareable6 left [04:56] *** linkable6 left [04:56] *** evalable6 left [04:56] *** squashable6 joined [04:57] *** shareable6 joined [04:57] *** tellable6 joined [04:57] *** linkable6 joined [04:57] *** sourceable6 joined [04:57] *** nativecallable6 joined [04:57] *** greppable6 joined [04:57] *** notable6 joined [04:58] *** benchable6 joined [04:58] *** committable6 joined [04:58] *** unicodable6 joined [04:58] *** statisfiable6 joined [04:58] *** releasable6 joined [04:59] *** quotable6 joined [04:59] *** evalable6 joined [04:59] *** bloatable6 joined [04:59] *** coverable6 joined [04:59] *** bisectable6 joined [07:06] good *, #moarvmable6 [07:27] *** domidumont joined [09:00] *** zakharyas joined [09:09] *** patrickb joined [10:18] so bot [10:18] morning o/ [10:45] such morning [10:46] * jnthn still has a grumpy arm :/ [10:53] * patrickb hopes this is about some computer not behaving well, but fears it's about the bodypart. [10:53] so bot | such morning | greet! [10:54] The bodypart, sadly [10:54] nwc: o/ there you go :-) [10:55] Thouugh I already have a work excuse to order an M1 :P [10:55] Was expecting to receive my new Ryzen box this week. Still haven't. [10:57] *** linkable6 left [10:57] *** evalable6 left [10:59] *** evalable6 joined [11:00] *** linkable6 joined [12:04] *** MasterDuke joined [12:10] inspiration did not strike overnight. but hopefully a fresh look this afternoon will reveal something [12:12] so the candidate is fine when put into the spesh slot. but it's garbage as soon as it's taken out [12:16] *** squashable6 left [12:16] *** squashable6 joined [12:22] which would indicate that the spesh slot does not get marked [12:26] i don't see anything that looks like other slots getting marked in optimize.c [12:28] So, how is this supposed to work? How does get stuff in spesh slots marked? We surely put MVMCollectables in there, don't we? [12:28] yeah, the signature is `MVM_spesh_add_spesh_slot(MVMThreadContext *tc, MVMSpeshGraph *g, MVMCollectable *c)` [12:29] *** leont joined [12:33] Ah gc_mark, in MVMSpeshCandidate.c [12:38] *** zakharyas left [12:43] those are different spesh slots, right? [12:46] https://github.com/MoarVM/MoarVM/blob/master/src/6model/reprs/MVMSpeshCandidate.h#L22-L23 vs https://github.com/MoarVM/MoarVM/blob/master/src/spesh/graph.h#L47-L48 [12:56] oh https://github.com/MoarVM/MoarVM/blob/master/src/spesh/graph.c#L1355 [13:30] Spesh slots are always collectables [13:33] OK, back to the nested resumption... [14:09] hm, i recorded the segv in rr, then put a watch on g->spesh_slots[12] (i confirmed 12 was the right balue), but nothing else writes there before the segv... [14:11] tried a read watch, so far hits at https://github.com/MoarVM/MoarVM/blob/master/src/spesh/graph.c#L1355 [14:12] and then the segv [14:24] * jnthn is still fixing compile errors :P [14:24] Only one left [14:30] Hurrah, now I get to hunt a segfault too :) [14:31] huh. i also went to interp.c right before the frame_invoke and put a watch and rwatch on tc->cur_frame->effective_spesh_slots[12] [14:31] and then reverse-continued [14:31] jnthn: start valgrind and put the kettle on? [14:32] Nah, it was a silly one, already fixed :) [14:32] Now I've got a legit panic telling me I forgot to implement something [14:33] and if i'm following what happens correctly (not 100% guaranteed), the only access is https://github.com/MoarVM/MoarVM/blob/master/src/spesh/optimize.c#L116 (the realloc in MVM_spesh_add_spesh_slot) [14:36] so i believe the spesh cand is stuck in the slot, then there's an unrelated MVM_spesh_candidate_add that triggers a bunch of other spesh_optimize/spesh_inline calls. those in turn call MVM_spesh_add_spesh_slot, causing a realloc [14:36] and the candidate is lost [15:20] *** patrickb left [15:29] well, i think i confused myself, but now i'm trying something else [15:34] aiui, tc->cur_frame->effective_spesh_slots is assigned spesh_cand->body.spesh_slots. so we stick the spesh candidate into a spesh graph's slots, those are copied to a candidate, then they're assigned to the frame. eventually that frame is invoked and its spesh slots become the tc->cur_frame->effective_spesh_slots [15:37] so what i did is set a breakpoint when we stick the spesh candidate in to a slot in optimize.c. then i set a breakpoint on MVM_frame_invoke and then stepped into it until the spesh_cand was assigned (if ever) because that's where the effective_spesh_slots were gotten from. then i checked the number of slots, and if there were enough, looked at the [15:37] 12th (cause that's the slot we stuck the candidate into back in optimize.c) [15:39] and there was never a spesh_cand that had enough slots and the 12th was the candidate stuck into that slot previously [15:39] and then we hit the segv [15:40] i still don't know why this is happening, but maybe the above triggers something for someone else [15:57] *** patrickb joined [16:03] Hurrah, first dispatch resumption tests where we fall back on an outer level of resumption work :) [16:04] congrats [16:04] "outer level of resumption" sounds like the precursor to outer hell, or so :-) [16:09] MasterDuke: you haven't pushed the new commits yet, have you? [16:09] :-D [16:18] The Rakudo commit to use all of that work is pleasingly small. https://github.com/rakudo/rakudo/commit/8d221325af47e9f761ff28a8a1987df37dd3d532 [16:19] .oO(When I grow up, I want to be a real commit) [16:19] indeed it is. One question, what is 2? [16:20] nine: just did [16:20] A value that wants to grow up to be a named constant, in this case meaning "we're doing a lastcall" [16:20] "when I grow up I want to have a name"? [16:20] Something like that :) [16:22] MasterDuke: that's much more fun to run in rr than yesterday's GC_DEBUG=3 version :) [16:22] heh, tell me about it [16:23] though i've been noticing something odd. the backtraces in gdb and rr take a noticeable time to appear/print [16:23] i.e., i type bt, first frame or two prints, then ~two seconds later the rest of the backtrace appears [16:25] not here [16:30] MasterDuke: what I see in rr is that what we get out of MVMSpeshCandidate *spesh_cand = (MVMSpeshCandidate *)tc->cur_frame->effective_spesh_slots[GET_UI16(cur_op, 4)]; is not a spesh candidate at all, but an NQPMatch object [16:31] huh. how did you figure that out? [16:31] oh, btw, i haven't implemented "invalidating the caller" [16:32] Break in src/core/interp.c:6000, reverse-cont to that from the segfault, then p *spesh_cand->common.st [16:32] assuming that you also get a segfault in allocate_frame [16:33] https://colabti.org/irclogger/irclogger_log/moarvm?date=2021-02-10#l115 [16:33] yep [16:34] oh, nice find [16:40] *** vrurg joined [17:03] re not having implemented invalidating the caller, that shouldn't be the problem right now, since no candidates have been removed before the segv [17:04] *** vrurg left [17:06] *** vrurg joined [17:18] *** vrurg left [17:30] *** vrurg joined [18:24] *** domidumont left [18:57] *** squashable6 left [18:58] *** squashable6 joined [20:36] *** patrickb left [22:40] *** kawaii left [22:41] *** kawaii joined