On Wed, 2012-04-11 at 17:47 +0300, Konstantin Belousov wrote: > On Wed, Apr 11, 2012 at 08:26:13AM -0600, Ian Lepore wrote: > > On Wed, 2012-04-11 at 16:11 +0200, Mel Flynn wrote: > > > Hi, > > > > > > I'm currently stuck on a bug in Zarafa-spooler that creates zombies. and > > > working around it by claiming that our pthread library isn't "normal" > > > which uses standard signals rather then a signal thread. > > > > > > My limited understanding of these facilities is however not enough to > > > see the actual problem here and reading of related manpages did not lead > > > me to a solution either. A test case reproducing the problem is attached. > > > > > > What happens is that SIGCHLD is never received by the signal thread and > > > the child processes turn to zombies. Signal counters never go up, not > > > even for SIGINFO, which I added specifically to see if anything gets > > > through at all. > > > > > > The signal thread shows being stuck in sigwait. It's reproducible on > > > 8.3-PRERELEASE of a few days ago (r233768). I'm not able to test it on > > > anything newer unfortunately, but I suspect this is a bug/linuxism in > > > the code not in FreeBSD. > > > > > > Thanks in advance for any insights. > > > _______________________________________________ > > > freebsd-hackers@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > > > > The signal mask for a new thread is inherited from the parent thread. > > In your example code, the signal handling thread inherits the blocked > > status of the signals as set up in main(). Try adding this line to > > signal_handler() before it goes into its while() loop: > > > > pthread_sigmask(SIG_UNBLOCK, &signal_mask, NULL); > > This is completely wrong. sigwait(2) requires the waited signals to be > blocked, so the code is right in this regard. >
Ooops, sorry. The code that sets up our signal handling threads uses SIG_SETMASK rather than BLOCK/UNBLOCK, and my quick glance at it misinterpretted what it was doing. -- Ian _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
