Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
Nicholas good *, * 05:51
nine * is good! 07:05
moon-child 'what a lot of things you do use good * for!' 08:15
lizmat I * it :-) 09:19
lizmat ok, I think I got a lead on #1920 10:18
so, looking at github.com/rakudo/rakudo/blob/mast...r.nqp#L245 10:19
if the setting has already been loaded, it doesn't do anything there 10:20
but I think it may not be doing enough in that case: if I put a debug message for the case that the setting was already loaded 10:21
it is *always* *that* debug message before the segfault
or completion, or hang
so my theory here is that somehow the "already loaded" branch is not doing enough 10:22
and that after that, the runloop goes into never never land, usually crashing, sometimes hanging
does that make sense? jnthnwrthngtn nine MasterDuke ^^ 10:23
jnthnwrthngtn You mean it never makes it to Loading bytecode from $path ? 10:25
jnthnwrthngtn notes it is holding $setting-lock
About the hang, notice this code is really fragile 10:26
If there's any exception, it shall never release the lock
lizmat so you mean it doesn't make sense to protect the global %settings_loaded hash ? 10:32
jnthnwrthngtn lizmat: I'm saying that if `find_setting` for example throws an exception, the lock is never released, so nothing can ever obtain it again, and that is maybe why there's a hang 10:33
lizmat the hangs were there *before* I introduced that lock already 10:34
jnthnwrthngtn OK, well, now there's a second way to hang ;)
Just needs a CATCH that releases the lock and rethrows
lizmat basically 8/10 segfault, 1/10 hang, 1/10 completed
jnthnwrthngtn What's the stacktrace of the segfault? 10:35
lizmat has no stacktrace of the segfault :-(
jnthnwrthngtn Is it reproducible with `rakudo-gdb-m`? 10:42
Oh, somebody posted taht in the issue 10:43
nine Parallel module loading has more than one way to segfault 10:44
lizmat jnthnwrthngtn: added an lldbm backtrace: github.com/rakudo/rakudo/issues/19...1084445196 11:22
lizmat it *always* stops there 11:23
hmmm... not always :-)
added another backtrace 11:24
lizmat added some more: but to me it looks like deserializing bytecode is not threadsafe 11:49

Powered by Cro and the Raku® Programming Language.

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

Thank you!