-[ Fri, Sep 02, 2011 at 11:26:42AM +0200, ri...@happyleptic.org ]---- > > 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).
