|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm 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 | |
| M#1333 | |||
| hmm | |||
|
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? 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 | |||
|
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 |
18:17 | |
| 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 | |
| # 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 | |
|
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
|
|||