[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [LTP] fatal signal handling
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
void handler(int sig)
printf("received signal %d\n",sig);
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.
Egor Duda wrote:
> 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:firstname.lastname@example.org ICQ 5165414 FidoNet 2:5020/496.19
email@example.com or firstname.lastname@example.org