Date: Mon, 05 Aug 1996 10:18:05 -0700 From: John Polstra <jdp@polstra.com> To: freebsd-current@freebsd.org Cc: bde@zeta.org.au, xaa@xaa.stack.urc.tue.nl, nate@freebsd.org Subject: Re: Bug: Signal handler won't stay installed (SOLVED) Message-ID: <199608051718.KAA15750@austin.polstra.com> In-Reply-To: <199608042010.NAA10207@austin.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In <199608042010.NAA10207@austin.polstra.com>, I wrote: > I've run into what looks like a kernel bug in a -current system > from around July 20th. > ... > The handler function gets called the first time a SIGCHLD happens, > but subsequent SIGCHLDs are ignored. The signals don't show up in > ktrace output at all, and the child processes stick around in the > zombie state. This happens only on my -current system; it works > fine on several -stable systems I've tried. This turned out NOT to be a kernel bug. It's pretty interesting, though. My program that failed is written in Modula-3. The runtime library's interface to the signal functions, roughly equivalent to C's <signal.h>, had a bug in it. I (thought I) was setting the flag SA_NOCLDSTOP in my call to sigaction, but the flag's value was defined wrong in the interface file. The correct value for this flag is 0x0008, but the interface file had it defined as 0x0004. So, why did it work under -stable, but not under -current? Because the meaning of the 0x0004 flag changed sometime between those two versions. In -stable, it is: #define SA_DISABLE 0x0004 /* disable taking signals on alternate stack */ but in -current it is: #define SA_RESETHAND 0x0004 /* reset to SIG_DFL when taking signal */ Sorry for the false alarm. Ya gotta admit, it's a nasty combination of, er, missed connections. Thanks to Bruce Evans for sending me a C program that should have failed under my original hypothesis, but didn't. -- John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608051718.KAA15750>