|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm 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 github.com/MoarVM/MoarVM/issues/1113 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 |
14:03 | |
| 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:15 | ||
|
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
|
|||