Re: open-pipe deadlocked

[rixed@happyleptic.org]

> For 1.8, could you try running Helgrind and see what happens?

Helgrind complains about loads of 'possible data race' but does not
detect anything wrong when the actual deadlock occurs. When I exit
the program it does tell that a threads still own some lock, but
does not reveal the addresses of those in a meaningfull way for me:

==26762== Thread #1: Exiting thread still holds 1 lock
==26762==    at 0x5A81B4D: waitpid (waitpid.c:41)
==26762==    by 0x4F0A289: scm_waitpid (posix.c:560)
==27182==    by 0x5A7BF09: pthread_mutex_lock (pthread_mutex_lock.c:61)
==26762==    by 0x4E8FCBF: deval (eval.c:4229)
==27182==    by 0x4C25BEF: pthread_mutex_lock (hg_intercepts.c:488)
==27182==    by 0x4EF6606: scm_i_thread_put_to_sleep (threads.c:1676)
==26762==    by 0x4E89B4F: scm_i_eval_x (eval.c:5900)
==27182==    by 0x4E96D93: scm_i_gc (gc.c:550)
==27182==    by 0x4E96CBC: scm_gc_for_newcell (gc.c:507)
==26762==    by 0x4E8FCED: deval (eval.c:4232)
==27182==    by 0x4EAC1B8: scm_cell (inline.h:122)
==26762==    by 0x4E89C62: scm_i_eval (eval.c:5910)
==26762==    by 0x4E710D7: scm_start_stack (debug.c:457)
==26762==    by 0x4E71199: scm_m_start_stack (debug.c:473)
==26762==
==27182==    by 0x4E91F5E: scm_dapply (eval.c:5012)
==27182==

(how pthread_mutex_lock apears to call scm_waitpid is not clear to me)

I don't know how helgrind works exactly, and thus can not be sure
its supposed to detect when a thread lock a mutex it already owns
(especially after a fork).

As to why it does not happen with guile2, this is still a mystery. My
theory about this deadlock is that the thread that calls open-process
owns the scm_i_port_table_mutex when open-process is called, and thus
the port-for-each call deadlock. But since
guile2's open-process does the same fork (not vfork), takes the same
scm_i_port_table_mutex in port-for-each, which mutex is still not
recursive, and yet does not deadlock, then maybe my theory is wrong in
the first place - or maybe the path that calls open-process while
scm_i_port_table_mutex is locked disapeared in guile2, maybe due to the
change of garbage collector (since the GC also grab this lock I
believe). Or maybe the deadlock involves another lock in addition to
this one. I'm going to turn scm_i_port_table_mutex into a recursive
mutex in order to try to invalidate my theory. sorry I'm thinking aloud
but maybe this can give you some better idea?