Date: Wed, 11 Apr 2012 16:44:44 +0200 From: Mel Flynn <rflynn@acsalaska.net> To: Ian Lepore <freebsd@damnhippie.dyndns.org> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Debugging zombies: pthread_sigmask and sigwait Message-ID: <4F8598DC.9010508@acsalaska.net> In-Reply-To: <1334154373.1082.110.camel@revolution.hippie.lan> References: <4F859112.5070005@acsalaska.net> <1334154373.1082.110.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4/11/2012 16:26, Ian Lepore wrote:
> On Wed, 2012-04-11 at 16:11 +0200, Mel Flynn wrote:
>> 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.
> 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);
That doesn't change anything and is in contrast to what sigwait(2) says:
The signals specified by set /should be blocked/ at the time of the
call to sigwait().
I also thought about a different child touching the signal code and two
processes blocked in sigwait in the original code (they fork a logger
process prior to sigemptyset()), but I explicitly avoid that in the test
case.
--
Mel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F8598DC.9010508>