Re: [LTP] fatal signal handling

[Aaron Laffin <laffinaw@acm.org>]

We've avoided this problem on Irix through a mechanism where the default
handler is reinstalled after a signal is received, meaning subsequent
signals if not blocked go to the default handler.  Irix signal() does
this by default.

I thought this also would be the case on Linux as the RedHat 6.2 man
page for signal(2) seems to indicate the same:

       Unlike  on  BSD  systems, signals under Linux are reset to
       their default  behavior  when  raised.   However,  if  you
       include  <bsd/signal.h>  instead of <signal.h> then signal
       is redefined as __bsd_signal and signal has the BSD seman<AD>
       tics.   Both versions of signal are library routines built
       on top of sigaction(2).

However, when I ran the following snippit, my rh6.2 system went into the
infinite recursion:

#include <signal.h>

void handler(int sig)
{
  printf("received signal %d\n",sig);
  raise(sig);
}

int main()
{
  signal(SIGTERM,handler);
  raise(SIGTERM);
}

The same code on Irix terminates from the raise() in the handler.  This
is what I expected on Linux.

My first question is what is the correct behavior?  Am I
misunderstanding that man page?  This is a continual problem I've
experienced with Linux: figuring out whether a behavior is correct or
not.  Linux traditionally has had its own little idiosyncrasies and
sometimes it is tough to figure out if some exotic behavior is an
intended behavior on Linux or a real problem.

This problem with signal() may be an artifact of the man pages not
keeping up with libc changes.  We may wish to move to direct use of
sigaction() as suggested.

--aaron

Egor Duda wrote:
> 
> Hi!
> 
>   currently,  tests  in  ltp  can possibly catch fatal signals such as
> SIGSEGV  recursively.  imagine  rmdir()  is faulty and causes SIGSEGV.
> tst_sig  sets  cleanup()  as  handler  for  SIGSEGV, but cleanup calls
> rmdir() itself. possible solutions are
> 
> 1. using sigaction() instead of signal()
> 2. checking "reentering" in handler
> 
> which way is preferable?
> 
> Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19

-- 
Aaron Laffin
laffinaw@acm.org or a.laffin@computer.org