Debugging zombies: pthread_sigmask and sigwait

[Ian Lepore]

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 at freebsd.org mailing list
> > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at 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