Another signal handling bug?

[David A. Gatwood]

On Wed, 16 Aug 2000, David A. Gatwood wrote:

> On Wed, 16 Aug 2000, David A. Gatwood wrote:
>
> > I've just noticed something that, unless I've really misunderstood the man
> > page, is another significant bug in signal handling.  Put simply, despite
> > configuration to the contrary, signals are not being blocked during their
> > handlers, i.e. I'm getting nested signal handlers that never return.
> >
> > The code in question basically does this:
> >
> > sa.sa_handler = alarm_handler;
> > sigemptyset(&sa.sa_mask);
> > sa.sa_flags = 0;
> > sigaction(SIGALRM, &sa, NULL);
>
> <snip>
>
> > Any ideas?  BTW, this is with kernel 2.2.12.  A similar bug was found and
> > fixed under MkLinux about a year ago, but I haven't heard of the problem
> > in the monolithic kernel.
>
> Well, the good news is that it is not kernel specific.  Same problem under
> MkLinux (plus a handful of race conditions that I'm trying to track down
> now... :-).
>
> Any idea how to convince sigaction to block the signal from being
> delivered within its signal handler (like the man page says it's always
> supposed to do)?

Oh, and I tried explicitly adding SIGALRM to the list of signals to be
blocked (with sigaddset).  Same result.


David

---------------------------------------------------------------------
A brief Haiku:

Microsoft is bad.
It seems secure at first glance.
Then you read your mail.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/