Node:Program Error Signals, Next:Termination Signals, Up:Standard Signals
The following signals are generated when a serious program error is detected by the operating system or the computer itself. In general, all of these signals are indications that your program is seriously broken in some way, and there's usually no way to continue the computation which encountered the error.
Some programs handle program error signals in order to tidy up before terminating; for example, programs that turn off echoing of terminal input should handle program error signals in order to turn echoing back on. The handler should end by specifying the default action for the signal that happened and then reraising it; this will cause the program to terminate with that signal, as if it had not had a handler. (See Termination in Handler.)
Termination is the sensible ultimate outcome from a program error in
most programs. However, programming systems such as Lisp that can load
compiled user programs might need to keep executing even if a user
program incurs an error. These programs have handlers which use
longjmp
to return control to the command level.
The default action for all of these signals is to cause the process to
terminate. If you block or ignore these signals or establish handlers
for them that return normally, your program will probably break horribly
when such signals happen, unless they are generated by raise
or
kill
instead of a real error.
When one of these program error signals terminates a process, it also
writes a core dump file which records the state of the process at
the time of termination. The core dump file is named core
and is
written in whichever directory is current in the process at the time.
(On the GNU system, you can specify the file name for core dumps with
the environment variable COREFILE
.) The purpose of core dump
files is so that you can examine them with a debugger to investigate
what caused the error.
int SIGFPE | Macro |
The SIGFPE signal reports a fatal arithmetic error. Although the
name is derived from "floating-point exception", this signal actually
covers all arithmetic errors, including division by zero and overflow.
If a program stores integer data in a location which is then used in a
floating-point operation, this often causes an "invalid operation"
exception, because the processor cannot recognize the data as a
floating-point number.
Actual floating-point exceptions are a complicated subject because there
are many types of exceptions with subtly different meanings, and the
|
BSD systems provide the SIGFPE
handler with an extra argument
that distinguishes various causes of the exception. In order to access
this argument, you must define the handler to accept two arguments,
which means you must cast it to a one-argument function type in order to
establish the handler. The GNU library does provide this extra
argument, but the value is meaningful only on operating systems that
provide the information (BSD systems and GNU systems).
FPE_INTOVF_TRAP
FPE_INTDIV_TRAP
FPE_SUBRNG_TRAP
FPE_FLTOVF_TRAP
FPE_FLTDIV_TRAP
FPE_FLTUND_TRAP
FPE_DECOVF_TRAP
int SIGILL | Macro |
The name of this signal is derived from "illegal instruction"; it
usually means your program is trying to execute garbage or a privileged
instruction. Since the C compiler generates only valid instructions,
SIGILL typically indicates that the executable file is corrupted,
or that you are trying to execute data. Some common ways of getting
into the latter situation are by passing an invalid object where a
pointer to a function was expected, or by writing past the end of an
automatic array (or similar problems with pointers to automatic
variables) and corrupting other data on the stack such as the return
address of a stack frame.
|
int SIGSEGV | Macro |
This signal is generated when a program tries to read or write outside
the memory that is allocated for it, or to write memory that can only be
read. (Actually, the signals only occur when the program goes far
enough outside to be detected by the system's memory protection
mechanism.) The name is an abbreviation for "segmentation violation".
Common ways of getting a |
int SIGBUS | Macro |
This signal is generated when an invalid pointer is dereferenced. Like
SIGSEGV , this signal is typically the result of dereferencing an
uninitialized pointer. The difference between the two is that
SIGSEGV indicates an invalid access to valid memory, while
SIGBUS indicates an access to an invalid address. In particular,
SIGBUS signals often result from dereferencing a misaligned
pointer, such as referring to a four-word integer at an address not
divisible by four. (Each kind of computer has its own requirements for
address alignment.)
The name of this signal is an abbreviation for "bus error". |
int SIGABRT | Macro |
This signal indicates an error detected by the program itself and
reported by calling abort . See Aborting a Program.
|
int SIGIOT | Macro |
Generated by the PDP-11 "iot" instruction. On most machines, this is
just another name for SIGABRT .
|
int SIGTRAP | Macro |
Generated by the machine's breakpoint instruction, and possibly other
trap instructions. This signal is used by debuggers. Your program will
probably only see SIGTRAP if it is somehow executing bad
instructions.
|
int SIGEMT | Macro |
Emulator trap; this results from certain unimplemented instructions which might be emulated in software, or the operating system's failure to properly emulate them. |
int SIGSYS | Macro |
Bad system call; that is to say, the instruction to trap to the operating system was executed, but the code number for the system call to perform was invalid. |