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.
01:32 japhb left 01:35 japhb joined 02:01 nine left 02:02 nine joined
Nicholas good *, * 05:51
06:39 kjp_ left 06:55 kjp joined
nine * is good! 07:05
moon-child 'what a lot of things you do use good * for!' 08:15
lizmat I * it :-) 09:19
09:42 ggoebel left
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
11:02 ggoebel joined
lizmat jnthnwrthngtn: added an lldbm backtrace: github.com/rakudo/rakudo/issues/19...1084445196 11:22
11:22 ggoebel left
lizmat it *always* stops there 11:23
hmmm... not always :-)
added another backtrace 11:24
11:31 ggoebel joined
lizmat added some more: but to me it looks like deserializing bytecode is not threadsafe 11:49
12:13 ggoebel left 12:55 ggoebel joined 15:02 discord-raku-bot left 15:03 discord-raku-bot joined 15:44 committable6 joined, bisectable6 joined, sourceable6 joined, bisectable6 left 15:45 quotable6 joined, coverable6 joined, linkable6 joined 15:46 notable6 joined, nativecallable6 joined, releasable6 joined, bloatable6 joined 15:47 reportable6 joined, bisectable6 joined 16:11 linkable6 left 16:14 linkable6 joined 18:16 reportable6 left 18:17 reportable6 joined 20:00 statisfiable6 joined 20:01 bisectable6 left 20:02 bisectable6 joined 20:03 benchable6 joined, squashable6 joined 20:04 unicodable6 joined, evalable6 joined, evalable6 left, benchable6 left, bisectable6 left, squashable6 left, statisfiable6 left, releasable6 left, linkable6 left, coverable6 left, quotable6 left, bloatable6 left, notable6 left, unicodable6 left, sourceable6 left, nativecallable6 left, reportable6 left, committable6 left, linkable6 joined, sourceable6 joined, squashable6 joined, greppable6 joined 20:05 reportable6 joined, statisfiable6 joined, shareable6 joined, notable6 joined, coverable6 joined, evalable6 joined 20:06 committable6 joined, unicodable6 joined, nativecallable6 joined, squashable6 left 20:07 quotable6 joined, bloatable6 joined, benchable6 joined, bisectable6 joined, releasable6 joined 22:38 discord-raku-bot left, discord-raku-bot joined, gfldex left 22:41 gfldex joined 22:44 discord-raku-bot left 22:45 discord-raku-bot joined 22:48 Techcable left 22:50 Techcable joined 22:53 Techcable left 22:55 Techcable joined