Re: open-pipe deadlocked

[rixed]

-[ Fri, Sep 02, 2011 at 11:26:42AM +0200, address@hidden ]----
> > For 1.8, could you try running Helgrind and see what happens?
> ==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 answer myself: there are actually 2 stacks frames here. This should be
read as:

> ==26762== Thread #1: Exiting thread still holds 1 lock
> ==26762==    at 0x5A81B4D: waitpid (waitpid.c:41)
> ==26762==    by 0x4F0A289: scm_waitpid (posix.c:560)
> ==26762==    by 0x4E8FCBF: deval (eval.c:4229)
> ==26762==    by 0x4E89B4F: scm_i_eval_x (eval.c:5900)
> ==26762==    by 0x4E8FCED: deval (eval.c:4232)
> ==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==

and

> ==27182==    by 0x5A7BF09: pthread_mutex_lock (pthread_mutex_lock.c:61)
> ==27182==    by 0x4C25BEF: pthread_mutex_lock (hg_intercepts.c:488)
> ==27182==    by 0x4EF6606: scm_i_thread_put_to_sleep (threads.c:1676)
> ==27182==    by 0x4E96D93: scm_i_gc (gc.c:550)
> ==27182==    by 0x4E96CBC: scm_gc_for_newcell (gc.c:507)
> ==27182==    by 0x4EAC1B8: scm_cell (inline.h:122)
> ==27182==    by 0x4E91F5E: scm_dapply (eval.c:5012)
> ==27182==

Which makes more sense.
(I suppose the first stackframe is where the thread exited and the
second where it took its lock from).