| IRC logs at
Set by AlexDaniel on 12 June 2018.
00:42 sena_kun left 00:56 sena_kun joined 02:42 sena_kun left 02:58 sena_kun joined 04:42 sena_kun left 04:57 sena_kun joined 05:57 evalable6 left 06:00 evalable6 joined 06:42 sena_kun left 06:57 sena_kun joined 08:11 sena_kun left 08:12 sena_kun joined 08:42 sena_kun left 08:55 sena_kun joined 10:15 timotimo left 10:35 sena_kun left 10:39 bartolin left, camelia left 10:42 xiaomiao left 10:46 xiaomiao joined 10:47 bartolin joined 10:49 camelia joined 10:50 sena_kun joined 11:37 Kaiepi joined 12:42 sena_kun left 12:56 sena_kun joined 13:23 lucasb joined 14:32 AlexDani` joined 14:34 AlexDaniel left 14:41 AlexDani` left 14:42 sena_kun left 14:58 sena_kun joined 15:28 domidumont joined 15:40 domidumont left 16:24 AlexDani` joined 16:33 patrickb joined 16:36 AlexDani` is now known as AlexDaniel, AlexDaniel left, AlexDaniel joined 16:42 sena_kun left 16:56 sena_kun joined 17:00 patrickb left 17:52 AlexDani` joined 17:54 AlexDaniel left 18:06 patrickb joined 18:42 sena_kun left 18:58 sena_kun joined 20:42 sena_kun left 20:56 sena_kun joined
Geth_ MoarVM/master: 5 commits pushed by (Stefan Seifert)++ 21:10
21:11 AlexDani` left, AlexDani` joined
Geth_ MoarVM: e94893f897 | (Stefan Seifert)++ | src/spesh/frame_walker.c
Fix frame walker segfaults caused by deopt of a caller on a different thread

When a frame schedules some code to be run on another frame, later gets deoptimized and the scheduled code is currently using the frame walker, e.g. looking for a dynamic variable, we could easily run into segfaults because the facts we checked changed right afterwards. Try to fix this by taking local copies of the pointers we will dereference, i.e. f->spesh_cand and f->jit_entry_label, as those may be removed by the deopt.
21:40 AlexDani` is now known as AlexDaniel, AlexDaniel left, AlexDaniel joined 22:41 sena_kun left 22:55 sena_kun joined 23:08 Geth_ left, Geth joined
japhb nine: Time for an nqp/rakudo bump after the above commits? 23:17
23:37 Kaiepi left 23:38 Kaiepi joined
jnthn nine: No problem with that; I need to look at it more closely to see if a deeper fix will be needed. 23:42