| <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> |
| |
