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
|