Eli Zaretskii <e...@gnu.org> skribis:
> There's only one thread at this point, its backtrace is below.
> Actually, I don't see more than this one thread during the entire run
> (GDB doesn't announce any thread birth or death, and Process Explorer
> shows a single thread in the process at all times). Note that we are
> talking about a child guile process -- it's that one that prints the
> weird traceback and hangs. The parent just waits for the child to
> finish.
Where’s the child process created exactly? It’s not clear to me.
Anyway, it could be that the parent Guile process has more than one
thread, and the child Guile process (which has only one thread) ends up
with some mutexes locked, and possibly inconsistent state.
Normally a Guile with multiple threads warns upon ‘fork’, precisely
because of this problem (see ‘scm_fork’ in posix.c.)
However, that warning doesn’t take into account the signal thread, nor
the GC thread (if any). So, although that seems unlikely, there could
still be issues, for instance if the ‘scm_fork’ call happens while
‘signal_delivery_thread_mutex’ is locked.
We would need to check if we are in such a scenario. Could you try a
small test case, something simple to start with:
(use-modules (ice-9 match))
(match (primitive-fork)
(0 (gc) (primitive-exit 0))
(child
(waitpid child)
(exit 0)))
TIA,
Ludo’.
