| IRC logs at
Set by AlexDaniel on 12 June 2018.
03:08 moon-child left 03:19 moon-child joined 04:47 tellable6 left, evalable6 left, greppable6 left, unicodable6 left, releasable6 left, statisfiable6 left, committable6 left, notable6 left, sourceable6 left, sourceable6 joined 04:48 notable6 joined 04:49 unicodable6 joined 04:50 committable6 joined 05:03 Altai-man_ joined 05:13 sena_kun left, japhb left, jjatria left 05:23 japhb joined, jjatria joined 08:14 domidumont joined 12:04 reportable6 joined
dogbert17 it's remarkably silent around here 13:04
lizmat it is, isn't it 13:12
13:42 unicodable6 left, notable6 left, notable6 joined 13:43 linkable6 joined 13:44 releasable6 joined 13:49 linkable6 left, committable6 left, sourceable6 left, notable6 left, reportable6 left, releasable6 left 13:52 evalable6 joined, nativecallable6 joined, quotable6 joined, bloatable6 joined, coverable6 joined, notable6 joined, benchable6 joined 13:53 sourceable6 joined, releasable6 joined, statisfiable6 joined 13:54 linkable6 joined, committable6 joined, squashable6 joined, reportable6 joined 13:55 bisectable6 joined, greppable6 joined, unicodable6 joined 13:56 shareable6 joined, tellable6 joined
dogbert17 I thought it would be a hive of activity, bugfixes and optimizations galore 14:11
lizmat not all work is immediately visible 14:12
lizmat just rendered the first daily page of a new logs website
and is now ready to be afk for a few hours& :-)
14:49 dogbert17 left 14:50 dogbert17 joined
nine I did work a bit on NativeCall memory management this morning, but then headed to the airfield to give a few flying lessons. Back now and will soon pick up my work :) 15:20
Alas, it's hard to say when this will ever come to fruition. I think I'm now on my 4th design 15:35
dogbert17 There's an easier bug that we can fix 16:02
16:03 linkable6 left
dogbert17 ah, that was too much for the bot 16:03
16:05 linkable6 joined
dogbert17 nine: do you remember this line? 16:08
nine What about it? 16:33
dogbert17 you thought that changing it to MVM_fixed_size_free_at_safepoint would resolve M#1333 16:46
16:46 linkable6 left
dogbert17 and that seems to be that case although it's difficult to prove 100% 16:47
16:47 domidumont left 16:48 linkable6 joined
nine Ah, yes, I start to remember it 17:15
dogbert17 so why does the _at_safepoint version fix the bug? 17:26
nine Short answer is: it doesn't. It merely makes it even less likely to appear. 17:42
So, what happens is that we start a task on a worker thread. This task then looks up a dynamic variable up the call chain and in the lexical context. 17:46
It can happen that we exit the caller frame precicely in the moment that the task's frame walker is processing this frame. When exiting we also clean up the frame extras which among onther things holds the dynvar cache. 17:47
Using the _at_safepoint version defers freeing that structure, so it won't happen that the thing gets freed while the frame walker is still using it.
dogbert17 but it could still happen then? 17:48
nine Actually I'm not sure and am now leaning towards no again. 17:49
The reason why I thought that it might still happen is that _at_safepoint means "during the next GC run". The frame walker can trigger GC, so _at_safepoint may still happen during the traversal. 17:50
But looking at MVM_frame_find_dynamic_using_frame_walker, we don't seem to access those frame extras for long, so could be that we're not running any frame walker code that can actually trigger GC. 17:51
I think the only place that we need to worry about is MVM_spesh_frame_walker_get_lex as that may viviy the lexical which may trigger gC.
dogbert17 would a proper fix need to change more than the one line in frame.c then? 17:53
nine If my reading of the code is correct, then no. Would be nice if someone else could do an independent reading though. 17:54
17:54 zakharyas joined
nine Also I wonder how we could safeguard such fragile constructs 17:54
dogbert17 perhaps I should write a issuecomment mentioning the proposed fix and a link to your comments here 17:59
18:01 reportable6 left
nine Or create the PR right away? 18:01
dogbert17 that's another alternative :)
18:02 reportable6 joined
Geth MoarVM: dogbert17++ created pull request #1485:
Fix heap-use-after-free in t/spec/S17-promise/nonblocking-await.t
dogbert17 nine: I more or less stole your comments verbatim 18:18
18:29 zakharyas left 18:51 zakharyas joined
nine dogbert17: I actually wanted to suggest just that :) 18:55
MasterDuke i've now seen this twice (once during one random run of my pipeline simplifying PR, and now once in dogbert17++'s PR) 19:02
# Failed test 'No unexpected entries in SETTING::'
# at t/02-rakudo/04-settingkeys-6e.t line 814
# You failed 1 test of 2
dogbert17 MasterDuke: I can't repro :( 19:50
MasterDuke i think both times i saw it in the MVM_clang_njit_libffi configuration 19:51
20:49 zakharyas left 20:50 zakharyas joined 20:54 leont left, chansen_ left, tbrowder left 20:55 tbrowder joined, leont joined 20:56 zakharyas left 20:57 chansen_ joined