Re: catching SIGFPE signal

"subramanian100in@xxxxxxxxx, India" <subramanian100in@xxxxxxxxx> writes:
I am using Redhat Enterprise Linux kernel 2.6.9 and gcc 3.4.3

consider the following program:

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>

void signal_handler_SIGFPE(int signum)
{
printf("SIGFPE caught: %d\n", signum);
return;
}

The output line "SIGFPE caught: 8" corresponds to the
signal_handler_SIGFPE() function. But after executing this handler,
control does not return to main(); but instead prints "Floating point
exception" and terminates the program.

Why doesn't the control go back to main() and continue processing ?
Does it mean that SIGFPE cannot be caught ?


The signal handler is called with two additional parameters in
addition to the signal number. The second parameter is a pointer
to a siginfo_t structure and the third parameter describes the
state of the thread at the time of the exception (ucontext_t
datatype, although POSIX lists it as void *).

The state at the time of the exception is recorded into the
ucontext_t structure (e.g. instruction pointer, general registers,
etc). When you return from the signal handler, the state will
be restored and execution will continue.

For SIGFPE, the state recorded in the ucontext_t structure will
include the starting address of the divide instruction that
generates your SIGFPE. When you return from the signal handler,
that instruction will be re-executed, and as you didn't re-install
the signal handler, your application terminates. If you had reinstalled
your signal handler, or used sigaction(2) instead of signal(2), you'd
find your application in an infinite loop.

The possibilities for recovery are:

1) Interpret the instruction that failed and fixup its arguments
such that when returning from the signal handler the divide won't fail, or
2) Bump the 'next instruction' address in the ucontext_t to the
next instruction and skip the div (although this will cause
unspecified bad things to happen because the div didn't happen), or
3) Use longjmp/siglongjmp to return to a known good state.
4) Abort the application.

Only (3) and (4) are viable choices in my opinion, particularly if
portability is desired.

scott
.

Relevant Pages

  • Re: Issue with SIGTRAP
    ... > Please post some sample code which demonstrates the problem you're seeing. ... I finally found my problem which was due to the fact that my signal handler was ... platforms I've dealt with instead of going back to the next instruction, ... therefore repeatedly doing the division by zero ...
    (comp.sys.sgi.misc)
  • Re: C++ - User aborts - exiting normally?
    ... like the idea, most of all, but look what happens: the compiler ... I start the programme, and it ... executing the signal handler (I realised that putting a cout << ...
    (comp.unix.programmer)
  • Re: What happens to threads after receiving signal
    ... > parallel to the thread executing signal handler. ... Then it will write core and terminate. ...
    (comp.programming.threads)
  • Re: signals and wait for event.
    ... > arrive whileexecuting a signal handler they'd block. ... malloc() is still not safe. ... that the signal may have arrived while the thread was executing code ...
    (comp.unix.programmer)
  • Re: Doubt on signal handler
    ... If we define a signal handler to where the control will go after the ... successful return from the signal handler? ... Barry Margolin, barmar@xxxxxxxxxxxx ...
    (comp.unix.programmer)