/share/doc/arm-arm-none-linux-gnueabi/html/libc/Program-Error-Signals.html
HTML | 252 lines | 167 code | 22 blank | 63 comment | 0 complexity | f696f761af22b6782e30c5d0411b9fb2 MD5 | raw file
Possible License(s): GPL-3.0
- <html lang="en">
- <head>
- <title>Program Error Signals - The GNU C Library</title>
- <meta http-equiv="Content-Type" content="text/html">
- <meta name="description" content="The GNU C Library">
- <meta name="generator" content="makeinfo 4.13">
- <link title="Top" rel="start" href="index.html#Top">
- <link rel="up" href="Standard-Signals.html#Standard-Signals" title="Standard Signals">
- <link rel="next" href="Termination-Signals.html#Termination-Signals" title="Termination Signals">
- <link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
- <!--
- This file documents the GNU C library.
- This is Edition 0.12, last updated 2007-10-27,
- of `The GNU C Library Reference Manual', for version
- 2.8 (Sourcery G++ Lite 2011.03-41).
- Copyright (C) 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2001, 2002,
- 2003, 2007, 2008, 2010 Free Software Foundation, Inc.
- Permission is granted to copy, distribute and/or modify this document
- under the terms of the GNU Free Documentation License, Version 1.3 or
- any later version published by the Free Software Foundation; with the
- Invariant Sections being ``Free Software Needs Free Documentation''
- and ``GNU Lesser General Public License'', the Front-Cover texts being
- ``A GNU Manual'', and with the Back-Cover Texts as in (a) below. A
- copy of the license is included in the section entitled "GNU Free
- Documentation License".
- (a) The FSF's Back-Cover Text is: ``You have the freedom to
- copy and modify this GNU manual. Buying copies from the FSF
- supports it in developing GNU and promoting software freedom.''-->
- <meta http-equiv="Content-Style-Type" content="text/css">
- <style type="text/css"><!--
- pre.display { font-family:inherit }
- pre.format { font-family:inherit }
- pre.smalldisplay { font-family:inherit; font-size:smaller }
- pre.smallformat { font-family:inherit; font-size:smaller }
- pre.smallexample { font-size:smaller }
- pre.smalllisp { font-size:smaller }
- span.sc { font-variant:small-caps }
- span.roman { font-family:serif; font-weight:normal; }
- span.sansserif { font-family:sans-serif; font-weight:normal; }
- --></style>
- <link rel="stylesheet" type="text/css" href="../cs.css">
- </head>
- <body>
- <div class="node">
- <a name="Program-Error-Signals"></a>
- <p>
- Next: <a rel="next" accesskey="n" href="Termination-Signals.html#Termination-Signals">Termination Signals</a>,
- Up: <a rel="up" accesskey="u" href="Standard-Signals.html#Standard-Signals">Standard Signals</a>
- <hr>
- </div>
- <h4 class="subsection">24.2.1 Program Error Signals</h4>
- <p><a name="index-program-error-signals-2824"></a>
- 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.
- <p>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 <a href="Termination-in-Handler.html#Termination-in-Handler">Termination in Handler</a>.)
- <p>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
- <code>longjmp</code> to return control to the command level.
- <p>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 <code>raise</code> or
- <code>kill</code> instead of a real error.
- <p><a name="index-COREFILE-2825"></a>When one of these program error signals terminates a process, it also
- writes a <dfn>core dump file</dfn> which records the state of the process at
- the time of termination. The core dump file is named <samp><span class="file">core</span></samp> 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 <code>COREFILE</code>.) The purpose of core dump
- files is so that you can examine them with a debugger to investigate
- what caused the error.
- <!-- signal.h -->
- <!-- ISO -->
- <div class="defun">
- — Macro: int <b>SIGFPE</b><var><a name="index-SIGFPE-2826"></a></var><br>
- <blockquote><p>The <code>SIGFPE</code> 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.
- <a name="index-exception-2827"></a><a name="index-floating_002dpoint-exception-2828"></a>
- Actual floating-point exceptions are a complicated subject because there
- are many types of exceptions with subtly different meanings, and the
- <code>SIGFPE</code> signal doesn't distinguish between them. The <cite>IEEE
- Standard for Binary Floating-Point Arithmetic (ANSI/IEEE Std 754-1985
- and ANSI/IEEE Std 854-1987)</cite>
- 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.
- </p></blockquote></div>
- <p>BSD systems provide the <code>SIGFPE</code> 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).
- <dl>
- <!-- signal.h -->
- <!-- BSD -->
- <dt><code>FPE_INTOVF_TRAP</code><dd><a name="index-FPE_005fINTOVF_005fTRAP-2829"></a>Integer overflow (impossible in a C program unless you enable overflow
- trapping in a hardware-specific fashion).
- <!-- signal.h -->
- <!-- BSD -->
- <br><dt><code>FPE_INTDIV_TRAP</code><dd><a name="index-FPE_005fINTDIV_005fTRAP-2830"></a>Integer division by zero.
- <!-- signal.h -->
- <!-- BSD -->
- <br><dt><code>FPE_SUBRNG_TRAP</code><dd><a name="index-FPE_005fSUBRNG_005fTRAP-2831"></a>Subscript-range (something that C programs never check for).
- <!-- signal.h -->
- <!-- BSD -->
- <br><dt><code>FPE_FLTOVF_TRAP</code><dd><a name="index-FPE_005fFLTOVF_005fTRAP-2832"></a>Floating overflow trap.
- <!-- signal.h -->
- <!-- BSD -->
- <br><dt><code>FPE_FLTDIV_TRAP</code><dd><a name="index-FPE_005fFLTDIV_005fTRAP-2833"></a>Floating/decimal division by zero.
- <!-- signal.h -->
- <!-- BSD -->
- <br><dt><code>FPE_FLTUND_TRAP</code><dd><a name="index-FPE_005fFLTUND_005fTRAP-2834"></a>Floating underflow trap. (Trapping on floating underflow is not
- normally enabled.)
- <!-- signal.h -->
- <!-- BSD -->
- <br><dt><code>FPE_DECOVF_TRAP</code><dd><a name="index-FPE_005fDECOVF_005fTRAP-2835"></a>Decimal overflow trap. (Only a few machines have decimal arithmetic and
- C never uses it.)
- </dl>
- <!-- signal.h -->
- <!-- ISO -->
- <div class="defun">
- — Macro: int <b>SIGILL</b><var><a name="index-SIGILL-2836"></a></var><br>
- <blockquote><p>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,
- <code>SIGILL</code> 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.
- <p><code>SIGILL</code> can also be generated when the stack overflows, or when
- the system has trouble running the handler for a signal.
- </p></blockquote></div>
- <a name="index-illegal-instruction-2837"></a>
- <!-- signal.h -->
- <!-- ISO -->
- <div class="defun">
- — Macro: int <b>SIGSEGV</b><var><a name="index-SIGSEGV-2838"></a></var><br>
- <blockquote><p><a name="index-segmentation-violation-2839"></a>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”.
- <p>Common ways of getting a <code>SIGSEGV</code> 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
- <code>SIGSEGV</code> or <code>SIGBUS</code>.
- </p></blockquote></div>
- <!-- signal.h -->
- <!-- BSD -->
- <div class="defun">
- — Macro: int <b>SIGBUS</b><var><a name="index-SIGBUS-2840"></a></var><br>
- <blockquote><p>This signal is generated when an invalid pointer is dereferenced. Like
- <code>SIGSEGV</code>, this signal is typically the result of dereferencing an
- uninitialized pointer. The difference between the two is that
- <code>SIGSEGV</code> indicates an invalid access to valid memory, while
- <code>SIGBUS</code> indicates an access to an invalid address. In particular,
- <code>SIGBUS</code> 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.)
- <p>The name of this signal is an abbreviation for “bus error”.
- </p></blockquote></div>
- <a name="index-bus-error-2841"></a>
- <!-- signal.h -->
- <!-- ISO -->
- <div class="defun">
- — Macro: int <b>SIGABRT</b><var><a name="index-SIGABRT-2842"></a></var><br>
- <blockquote><p><a name="index-abort-signal-2843"></a>This signal indicates an error detected by the program itself and
- reported by calling <code>abort</code>. See <a href="Aborting-a-Program.html#Aborting-a-Program">Aborting a Program</a>.
- </p></blockquote></div>
- <!-- signal.h -->
- <!-- Unix -->
- <div class="defun">
- — Macro: int <b>SIGIOT</b><var><a name="index-SIGIOT-2844"></a></var><br>
- <blockquote><p>Generated by the PDP-11 “iot” instruction. On most machines, this is
- just another name for <code>SIGABRT</code>.
- </p></blockquote></div>
- <!-- signal.h -->
- <!-- BSD -->
- <div class="defun">
- — Macro: int <b>SIGTRAP</b><var><a name="index-SIGTRAP-2845"></a></var><br>
- <blockquote><p>Generated by the machine's breakpoint instruction, and possibly other
- trap instructions. This signal is used by debuggers. Your program will
- probably only see <code>SIGTRAP</code> if it is somehow executing bad
- instructions.
- </p></blockquote></div>
- <!-- signal.h -->
- <!-- BSD -->
- <div class="defun">
- — Macro: int <b>SIGEMT</b><var><a name="index-SIGEMT-2846"></a></var><br>
- <blockquote><p>Emulator trap; this results from certain unimplemented instructions
- which might be emulated in software, or the operating system's
- failure to properly emulate them.
- </p></blockquote></div>
- <!-- signal.h -->
- <!-- Unix -->
- <div class="defun">
- — Macro: int <b>SIGSYS</b><var><a name="index-SIGSYS-2847"></a></var><br>
- <blockquote><p>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.
- </p></blockquote></div>
- </body></html>