Another signal handling bug?

[Kevin B. Hendricks]

Hi David,

Two things:

1. setting the sa_mask to sigemptyset will not mask out any signals in your
handler (see the sigaction man page).  I think you want sigfillset if you want
to mask all signals while in your handler.  Here is a snippet from the sigaction
man page.

       sa_mask gives a mask of signals which  should  be  blocked
       during  execution of the signal handler.  In addition, the
       signal which triggered the handler will be blocked, unless
       the SA_NODEFER or SA_NOMASK flags are used.

2.  You should techically always be calling async signal safe routines
frominside any signal handlers.  Grabbing a mutex lock is not one of these.  You
can sometimes work around this using semaphore posts (which are technically
allowed) inside signal handlers since they are async signal safe.


Hope this helps.

Kevin

.
"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);
>
> Well, I know why the one handler didn't return -- there was the nasty
> little point of it trying to take a lock twice.  After fixing that, the
> signal handler _happens_ to always return before the next signal gets
> delivered.  However, obviously that doesn't solve the real issue, since
> any heavy system load could cause that "luck" to no longer hold true.
> Fortunately, for my code's purposes, that is good enough, as long as the
> pthreads locks are correct, but it's still somewhat scary.  :-)
>
> Ideas?
> 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/