Program Error 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. (Note: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.
- Macro: int SIGFPE
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 `SIGFPE' signal doesn't distinguish between them. The
`IEEE Standard for Binary Floating-Point Arithmetic (ANSI/IEEE Std
754-1985 and ANSI/IEEE Std 854-1987)' defines various
floating-point exceptions and requires conforming computer systems
to report their occurrences. However, this standard does not
specify how the exceptions are reported, or what kinds of handling
and control the operating system can offer to the programmer.
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'
Integer overflow (impossible in a C program unless you enable
overflow trapping in a hardware-specific fashion).
`FPE_INTDIV_TRAP'
Integer division by zero.
`FPE_SUBRNG_TRAP'
Subscript-range (something that C programs never check for).
`FPE_FLTOVF_TRAP'
Floating overflow trap.
`FPE_FLTDIV_TRAP'
Floating/decimal division by zero.
`FPE_FLTUND_TRAP'
Floating underflow trap. (Trapping on floating underflow is not
normally enabled.)
`FPE_DECOVF_TRAP'
Decimal overflow trap. (Only a few machines have decimal
arithmetic and C never uses it.)
- Macro: int SIGILL
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.
`SIGILL' can also be generated when the stack overflows, or when
the system has trouble running the handler for a signal.
- Macro: int SIGSEGV
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 `SIGSEGV' condition include dereferencing
a null or uninitialized pointer, or when you use a pointer to step
through an array, but fail to check for the end of the array. It
varies among systems whether dereferencing a null pointer generates
`SIGSEGV' or `SIGBUS'.
- Macro: int SIGBUS
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".
- Macro: int SIGABRT
This signal indicates an error detected by the program itself and
reported by calling `abort'. Note:Aborting a Program.
- Macro: int SIGIOT
Generated by the PDP-11 "iot" instruction. On most machines, this
is just another name for `SIGABRT'.
- Macro: int SIGTRAP
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.
- Macro: int SIGEMT
Emulator trap; this results from certain unimplemented instructions
which might be emulated in software, or the operating system's
failure to properly emulate them.
- Macro: int SIGSYS
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.