| IRC logs at
Set by AlexDaniel on 12 June 2018.
MasterDuke yeah, added a print if it's passed in, only happens once and then the segv 00:00
in the very first file of the nqp build 00:01
jnthn 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:02
This all looks annoyingly simple/correct :) 00:03
Which means when we figure out I'll feel silly
MasterDuke heh, yep
(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 <inv_arg_callsite>,
    type_tuple = 0x7ffff00063b0, discarded = 0 '\000', bytecode_size = 2180, bytecode = 0x7ffff00e93e0 <incomplete sequence \367>, handlers = 0x7ffff003c5f0, spesh_slots = 0x7ffff00e2f60, num_spesh_slots = 38, num_deopts = 96,
    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},
    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,
    deopt_usage_info = 0x7ffff00ea9e0}}
that looks better 00:05
btw, the segv is here
huh. the spesh_cand_slot was 12 00:15
i then put a breakpoint in interp.c's sp_fastinvoke_o 00:16
right before the MVM_frame_invoke call
and continued 00:17
but GET_UI16(cur_op, 4) was 18
nm, that was after cur_op += 6; 00:19
GET_UI16(cur_op, 4) when getting the spesh slot was in fact 12 00:20
00:24 dogbert17 joined 00:28 dogbert12 left
jnthn Hm, odd 00:31
I should sleep, 'night o/
MasterDuke same here
01:26 MasterDuke left 03:53 quotable6 left, greppable6 left, notable6 left, bloatable6 left, committable6 left, bisectable6 left, linkable6 left, nativecallable6 left, statisfiable6 left, coverable6 left, unicodable6 left, shareable6 left, evalable6 left, benchable6 left, squashable6 left, releasable6 left, tellable6 left, sourceable6 left 03:54 evalable6 joined, committable6 joined, nativecallable6 joined, releasable6 joined, bisectable6 joined, sourceable6 joined, tellable6 joined, bloatable6 joined 03:55 linkable6 joined, coverable6 joined, greppable6 joined, shareable6 joined 03:56 benchable6 joined, squashable6 joined, notable6 joined, statisfiable6 joined, unicodable6 joined, quotable6 joined 04:56 coverable6 left, quotable6 left, sourceable6 left, unicodable6 left, greppable6 left, bloatable6 left, nativecallable6 left, committable6 left, benchable6 left, notable6 left, statisfiable6 left, tellable6 left, squashable6 left, bisectable6 left, releasable6 left, shareable6 left, linkable6 left, evalable6 left, squashable6 joined 04:57 shareable6 joined, tellable6 joined, linkable6 joined, sourceable6 joined, nativecallable6 joined, greppable6 joined, notable6 joined 04:58 benchable6 joined, committable6 joined, unicodable6 joined, statisfiable6 joined, releasable6 joined 04:59 quotable6 joined, evalable6 joined, bloatable6 joined, coverable6 joined, bisectable6 joined
nwc10 good *, #moarvmable6 07:06
07:27 domidumont joined 09:00 zakharyas joined 09:09 patrickb joined
jnthn so bot 10:18
morning o/
nwc10 such morning 10:45
jnthn still has a grumpy arm :/ 10:46
patrickb hopes this is about some computer not behaving well, but fears it's about the bodypart. 10:53
nwc10 so bot | such morning | greet!
jnthn The bodypart, sadly 10:54
patrickb nwc: o/ there you go :-)
jnthn 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, evalable6 left 10:59 evalable6 joined 11:00 linkable6 joined 12:04 MasterDuke joined
MasterDuke inspiration did not strike overnight. but hopefully a fresh look this afternoon will reveal something 12:10
so the candidate is fine when put into the spesh slot. but it's garbage as soon as it's taken out 12:12
12:16 squashable6 left, squashable6 joined
nine which would indicate that the spesh slot does not get marked 12:22
MasterDuke i don't see anything that looks like other slots getting marked in optimize.c 12:26
nine 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
MasterDuke yeah, the signature is `MVM_spesh_add_spesh_slot(MVMThreadContext *tc, MVMSpeshGraph *g, MVMCollectable *c)`
12:29 leont joined
nine Ah gc_mark, in MVMSpeshCandidate.c 12:33
12:38 zakharyas left
MasterDuke those are different spesh slots, right? 12:43 vs 12:46
oh 12:56
jnthn Spesh slots are always collectables 13:30
OK, back to the nested resumption... 13:33
MasterDuke 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:09
tried a read watch, so far hits at 14:11
and then the segv 14:12
jnthn is still fixing compile errors :P 14:24
Only one left
Hurrah, now I get to hunt a segfault too :) 14:30
MasterDuke 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
nwc10 jnthn: start valgrind and put the kettle on?
jnthn Nah, it was a silly one, already fixed :) 14:32
Now I've got a legit panic telling me I forgot to implement something
MasterDuke and if i'm following what happens correctly (not 100% guaranteed), the only access is (the realloc in MVM_spesh_add_spesh_slot) 14:33
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
MasterDuke well, i think i confused myself, but now i'm trying something else 15:29
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:34
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)
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
i still don't know why this is happening, but maybe the above triggers something for someone else 15:40
15:57 patrickb joined
jnthn Hurrah, first dispatch resumption tests where we fall back on an outer level of resumption work :) 16:03
moritz congrats 16:04
"outer level of resumption" sounds like the precursor to outer hell, or so :-)
nine MasterDuke: you haven't pushed the new commits yet, have you? 16:09
jnthn :-D
The Rakudo commit to use all of that work is pleasingly small. 16:18
.oO(When I grow up, I want to be a real commit)
nwc10 indeed it is. One question, what is 2?
MasterDuke nine: just did 16:20
jnthn A value that wants to grow up to be a named constant, in this case meaning "we're doing a lastcall"
nwc10 "when I grow up I want to have a name"?
jnthn Something like that :)
nine MasterDuke: that's much more fun to run in rr than yesterday's GC_DEBUG=3 version :) 16:22
MasterDuke heh, tell me about it
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
nine not here 16:25
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:30
MasterDuke huh. how did you figure that out? 16:31
oh, btw, i haven't implemented "invalidating the caller"
nine Break in src/core/interp.c:6000, reverse-cont to that from the segfault, then p *spesh_cand-> 16:32
assuming that you also get a segfault in allocate_frame
MasterDuke 16:33
oh, nice find 16:34
16:40 vrurg joined
MasterDuke 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:03
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