|
From: Godmar B. <go...@gm...> - 2005-02-18 15:34:06
|
Hi, I have a program for which valgrind 2.1.0 flags a deadlock condition because it doesn't take into account that a sigitimer-delivered signal will resume waiting threads in the future via sem_post(). It seems to me that valgrind should be more conservative in bailing when signals are involved, or provide an option to turn deadlock detection off. My question is whether there is such an option in valgrind? - Godmar PS 1: On a related note, I noticed this stack trace: ==14308== at 0x4022AFAD: pthread_cond_wait (vg_libpthread.c:1087) ==14308== by 0x4022CDC9: sem_wait (vg_libpthread.c:2328) which would seem to imply that sem_post might be implemented via pthread_cond_signal. This seems surprising to me in the sense that you'd then implement an async-signal-safe function (sem_post) on top of one that is commonly async-signal-unsafe (pthread_cond_signal) - I hope you considered this when implementing your pthread_cond_signal. PS 2: A work-around for my problem is to fire off an additional thread that does for(;;) sleep(1) - valgrind's scheduler will not flag a deadlock in that case. |
|
From: Nicholas N. <nj...@cs...> - 2005-02-19 00:13:53
|
On Fri, 18 Feb 2005, Godmar Back wrote: > I have a program for which valgrind 2.1.0 flags a deadlock condition > because it doesn't take into account that a sigitimer-delivered signal > will resume waiting threads in the future via sem_post(). It seems to > me that valgrind should be more conservative in bailing when signals > are involved, or provide an option to turn deadlock detection off. > > My question is whether there is such an option in valgrind? Not that I know of. But if you try the CVS HEAD, we now use the native pthread library rather than our own, so the problem might go away. N |