| IRC logs at
Set by AlexDaniel on 12 June 2018.
00:41 sena_kun left 00:56 sena_kun joined 01:50 ZzZombo_ joined 01:53 ZzZombo left, ZzZombo_ is now known as ZzZombo 02:05 Merfont left 02:06 Merfont joined 02:15 AlexDani` is now known as AlexDaniel, AlexDaniel left, AlexDaniel joined 02:41 sena_kun left 02:57 sena_kun joined 03:11 AlexDani` joined 03:12 AlexDaniel left 04:35 evalable6 left 04:37 evalable6 joined 04:40 sena_kun left 04:57 Voldenet left, sena_kun joined 05:03 Voldenet joined, Voldenet left, Voldenet joined 05:09 squashable6 left 05:11 squashable6 joined 05:53 squashable6 left 05:55 squashable6 joined 06:42 sena_kun left 06:57 sena_kun joined 07:19 ZzZombo left 07:26 squashable6 left 07:29 squashable6 joined 07:49 squashable6 left 07:50 squashable6 joined 08:42 sena_kun left 08:58 sena_kun joined 09:14 domidumont joined 10:41 sena_kun left 10:55 sena_kun joined 11:31 AlexDani` is now known as AlexDaniel, AlexDaniel left, AlexDaniel joined 12:17 zakharyas joined 12:27 zakharyas left 12:41 sena_kun left 12:55 sena_kun joined 12:58 brrt joined
brrt \o 13:05
13:10 brrt left
nine Oh, I cought the frame walker issue in rr for the first time! And it's....weird. As suspected, the frame's spesh cand gets cleared by a deopt, in another thread. 13:26
Which I don't know how that's possible. Especially since it's a deopt_one
For my future reference: it's rr/perl6-2863 13:27
Oh, wait a minute! What if that deopting frame is simply in the caller chain of the frame we started looking for a dynamic variable, but we were not just called but run in a different thread? 13:30
13:33 brrt joined
nine And indeed it is: 13:34
(rr) p initial_frame->caller->caller->caller->caller->caller->caller->caller->caller->caller->caller->caller->caller->caller->caller->caller->caller->caller->caller->caller->caller->caller->caller->caller->caller->caller->caller->caller
$42 = (MVMFrame *) 0x7fb68c8122a8
(rr) thread 21
[Switching to thread 21 (Thread 17607.17626)]
#0 deopt_frame (tc=0x6135370, f=0x7fb68c8122a8, deopt_idx=50, deopt_offset=474, deopt_target=110) at src/spesh/deopt.c:255
So walking the stack is just not thread safe 13:35
brrt ohai nine 13:37
how even
what did I miss
nine brrt: I finally made some progress on after finding a way to reproduce and cathing it in rr 13:38
brrt :-( 13:40
assumption breakage
nine The issue comes down to deoptimization of a call frame that spawned a frame on another thread that's looking for a dynamic variable
brrt ouch
nine So now I wonder: can this be salvaged by getting a local copy of a frame's spesh_cand pointer before checking and dereferencing it? Or is this more of an architectural problem? 13:41
I guess it comes down to: what happens to spesh_cands after deoptimization? I only see that f->spesh_cand is assigned NULL.
brrt I sort of thought they were garbage collected but I daren't say for sure 13:42
nah, MVMSpeshCandidate doesn't have a header
nine Ah, of course, that would make sense. So rooting would keep them alive long enough
brrt but there may be some object that does
nine The only place where we free a spesh candidate is in MVMStaticFrameSpesh's gc_free 13:43
So, we'd need to keep that alive 13:44
brrt well, if we deopt, we don't immediately destroy the static frames' spesh info
far from it, we'll just try again 13:45
so yeah, I think that taking the pointer before checking will work. But... I'm not 100% on whether you'll also take dead information then?
I mean, correct me if I'm wrong, but we check the spesh cand in order to check something about the frame lexicals array... and if frame is deoptimized, won't the lexicals array also have changed? 13:46
I'm totally out of practice on that piece of code so the odds that I'm wrong are somewhat larger than usual 13:47
nine Well, I've never been that much into this code :D 13:48
brrt hmmm, let me have a look 13:51
hmmm 13:52
yeah, that doesn't look very threadsafe indeed
nine Well, being more careful about spesh_cand does make it a lot more stable 13:59
Geth_ MoarVM/maybe_fix_frame_walker_segfaults: c4f0a8ca7b | (Stefan Seifert)++ | src/spesh/frame_walker.c
Fix frame walker segfaults caused by deopt of a caller on a different thread
MoarVM/maybe_fix_frame_walker_segfaults: ef830eb87c | (Stefan Seifert)++ | src/spesh/frame_walker.c
Fix frame walker segfaults caused by deopt of a caller on a different thread
14:41 sena_kun left 14:57 sena_kun joined 15:00 brrt left 16:01 Merfont left 16:42 sena_kun left 16:59 sena_kun joined 18:20 domidumont left 18:41 sena_kun left 18:57 sena_kun joined 20:12 squashable6 left 20:14 squashable6 joined 20:22 squashable6 left, squashable6 joined 20:42 sena_kun left 20:58 sena_kun joined 21:34 harrow left 21:41 harrow joined 22:42 sena_kun left 22:56 sena_kun joined 23:22 AlexDaniel left 23:24 AlexDaniel joined, AlexDaniel left, AlexDaniel joined 23:38 squashable6 left 23:39 squashable6 joined