Re: Another signal handling bug?

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

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

quoted

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>

quoted

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/