github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
dogbert17 it's remarkably silent around here 13:04
lizmat it is, isn't it 13:12
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& :-)
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
M#1333
hmm
dogbert17 ah, that was too much for the bot 16:03
dogbert17 nine: do you remember this line? github.com/MoarVM/MoarVM/blob/mast...ame.c#L885 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
github.com/MoarVM/MoarVM/issues/1333
dogbert17 and that seems to be that case although it's difficult to prove 100% 16:47
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
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
nine Or create the PR right away? 18:01
dogbert17 that's another alternative :)
Geth MoarVM: dogbert17++ created pull request #1485:
Fix heap-use-after-free in t/spec/S17-promise/nonblocking-await.t		 18:17
dogbert17 nine: I more or less stole your comments verbatim 18:18
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
# Found 12 unexpected entries: $?CLASS $?PACKAGE $pseudoers ::?CLASS ::?PACKAGE CtxSymIterator CtxWalker DYNAMIC_CHAIN PICK_CHAIN_BY_NAME PRECISE_SCOPE REQUIRE_DYNAMIC STATIC_CHAIN 19:03
# Failed test 'No unexpected entries in SETTING::'
# at t/02-rakudo/04-settingkeys-6e.t line 814
# You failed 1 test of 2
t/02-rakudo/04-settingkeys-6e.t
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

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!