PageRenderTime 3ms CodeModel.GetById 14ms app.highlight 5ms RepoModel.GetById 1ms app.codeStats 0ms

/share/doc/arm-arm-none-linux-gnueabi/html/libc/Program-Error-Signals.html

https://github.com/apc-io/apc-rock-toolchain
HTML | 252 lines | 167 code | 22 blank | 63 comment | 0 complexity | f696f761af22b6782e30c5d0411b9fb2 MD5 | raw file
  1<html lang="en">
  2<head>
  3<title>Program Error Signals - The GNU C Library</title>
  4<meta http-equiv="Content-Type" content="text/html">
  5<meta name="description" content="The GNU C Library">
  6<meta name="generator" content="makeinfo 4.13">
  7<link title="Top" rel="start" href="index.html#Top">
  8<link rel="up" href="Standard-Signals.html#Standard-Signals" title="Standard Signals">
  9<link rel="next" href="Termination-Signals.html#Termination-Signals" title="Termination Signals">
 10<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
 11<!--
 12This file documents the GNU C library.
 13
 14This is Edition 0.12, last updated 2007-10-27,
 15of `The GNU C Library Reference Manual', for version
 162.8 (Sourcery G++ Lite 2011.03-41).
 17
 18Copyright (C) 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2001, 2002,
 192003, 2007, 2008, 2010 Free Software Foundation, Inc.
 20
 21Permission is granted to copy, distribute and/or modify this document
 22under the terms of the GNU Free Documentation License, Version 1.3 or
 23any later version published by the Free Software Foundation; with the
 24Invariant Sections being ``Free Software Needs Free Documentation''
 25and ``GNU Lesser General Public License'', the Front-Cover texts being
 26``A GNU Manual'', and with the Back-Cover Texts as in (a) below.  A
 27copy of the license is included in the section entitled "GNU Free
 28Documentation License".
 29
 30(a) The FSF's Back-Cover Text is: ``You have the freedom to
 31copy and modify this GNU manual.  Buying copies from the FSF
 32supports it in developing GNU and promoting software freedom.''-->
 33<meta http-equiv="Content-Style-Type" content="text/css">
 34<style type="text/css"><!--
 35  pre.display { font-family:inherit }
 36  pre.format  { font-family:inherit }
 37  pre.smalldisplay { font-family:inherit; font-size:smaller }
 38  pre.smallformat  { font-family:inherit; font-size:smaller }
 39  pre.smallexample { font-size:smaller }
 40  pre.smalllisp    { font-size:smaller }
 41  span.sc    { font-variant:small-caps }
 42  span.roman { font-family:serif; font-weight:normal; } 
 43  span.sansserif { font-family:sans-serif; font-weight:normal; } 
 44--></style>
 45<link rel="stylesheet" type="text/css" href="../cs.css">
 46</head>
 47<body>
 48<div class="node">
 49<a name="Program-Error-Signals"></a>
 50<p>
 51Next:&nbsp;<a rel="next" accesskey="n" href="Termination-Signals.html#Termination-Signals">Termination Signals</a>,
 52Up:&nbsp;<a rel="up" accesskey="u" href="Standard-Signals.html#Standard-Signals">Standard Signals</a>
 53<hr>
 54</div>
 55
 56<h4 class="subsection">24.2.1 Program Error Signals</h4>
 57
 58<p><a name="index-program-error-signals-2824"></a>
 59The following signals are generated when a serious program error is
 60detected by the operating system or the computer itself.  In general,
 61all of these signals are indications that your program is seriously
 62broken in some way, and there's usually no way to continue the
 63computation which encountered the error.
 64
 65   <p>Some programs handle program error signals in order to tidy up before
 66terminating; for example, programs that turn off echoing of terminal
 67input should handle program error signals in order to turn echoing back
 68on.  The handler should end by specifying the default action for the
 69signal that happened and then reraising it; this will cause the program
 70to terminate with that signal, as if it had not had a handler. 
 71(See <a href="Termination-in-Handler.html#Termination-in-Handler">Termination in Handler</a>.)
 72
 73   <p>Termination is the sensible ultimate outcome from a program error in
 74most programs.  However, programming systems such as Lisp that can load
 75compiled user programs might need to keep executing even if a user
 76program incurs an error.  These programs have handlers which use
 77<code>longjmp</code> to return control to the command level.
 78
 79   <p>The default action for all of these signals is to cause the process to
 80terminate.  If you block or ignore these signals or establish handlers
 81for them that return normally, your program will probably break horribly
 82when such signals happen, unless they are generated by <code>raise</code> or
 83<code>kill</code> instead of a real error.
 84
 85   <p><a name="index-COREFILE-2825"></a>When one of these program error signals terminates a process, it also
 86writes a <dfn>core dump file</dfn> which records the state of the process at
 87the time of termination.  The core dump file is named <samp><span class="file">core</span></samp> and is
 88written in whichever directory is current in the process at the time. 
 89(On the GNU system, you can specify the file name for core dumps with
 90the environment variable <code>COREFILE</code>.)  The purpose of core dump
 91files is so that you can examine them with a debugger to investigate
 92what caused the error.
 93
 94<!-- signal.h -->
 95<!-- ISO -->
 96<div class="defun">
 97&mdash; Macro: int <b>SIGFPE</b><var><a name="index-SIGFPE-2826"></a></var><br>
 98<blockquote><p>The <code>SIGFPE</code> signal reports a fatal arithmetic error.  Although the
 99name is derived from &ldquo;floating-point exception&rdquo;, this signal actually
100covers all arithmetic errors, including division by zero and overflow. 
101If a program stores integer data in a location which is then used in a
102floating-point operation, this often causes an &ldquo;invalid operation&rdquo;
103exception, because the processor cannot recognize the data as a
104floating-point number. 
105<a name="index-exception-2827"></a><a name="index-floating_002dpoint-exception-2828"></a>
106Actual floating-point exceptions are a complicated subject because there
107are many types of exceptions with subtly different meanings, and the
108<code>SIGFPE</code> signal doesn't distinguish between them.  The <cite>IEEE
109Standard for Binary Floating-Point Arithmetic (ANSI/IEEE Std 754-1985
110and ANSI/IEEE Std 854-1987)</cite>
111defines various floating-point exceptions and requires conforming
112computer systems to report their occurrences.  However, this standard
113does not specify how the exceptions are reported, or what kinds of
114handling and control the operating system can offer to the programmer. 
115</p></blockquote></div>
116
117   <p>BSD systems provide the <code>SIGFPE</code> handler with an extra argument
118that distinguishes various causes of the exception.  In order to access
119this argument, you must define the handler to accept two arguments,
120which means you must cast it to a one-argument function type in order to
121establish the handler.  The GNU library does provide this extra
122argument, but the value is meaningful only on operating systems that
123provide the information (BSD systems and GNU systems).
124
125     <dl>
126<!-- signal.h -->
127<!-- BSD -->
128<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
129trapping in a hardware-specific fashion). 
130<!-- signal.h -->
131<!-- BSD -->
132<br><dt><code>FPE_INTDIV_TRAP</code><dd><a name="index-FPE_005fINTDIV_005fTRAP-2830"></a>Integer division by zero. 
133<!-- signal.h -->
134<!-- BSD -->
135<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). 
136<!-- signal.h -->
137<!-- BSD -->
138<br><dt><code>FPE_FLTOVF_TRAP</code><dd><a name="index-FPE_005fFLTOVF_005fTRAP-2832"></a>Floating overflow trap. 
139<!-- signal.h -->
140<!-- BSD -->
141<br><dt><code>FPE_FLTDIV_TRAP</code><dd><a name="index-FPE_005fFLTDIV_005fTRAP-2833"></a>Floating/decimal division by zero. 
142<!-- signal.h -->
143<!-- BSD -->
144<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
145normally enabled.) 
146<!-- signal.h -->
147<!-- BSD -->
148<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
149C never uses it.) 
150</dl>
151
152<!-- signal.h -->
153<!-- ISO -->
154<div class="defun">
155&mdash; Macro: int <b>SIGILL</b><var><a name="index-SIGILL-2836"></a></var><br>
156<blockquote><p>The name of this signal is derived from &ldquo;illegal instruction&rdquo;; it
157usually means your program is trying to execute garbage or a privileged
158instruction.  Since the C compiler generates only valid instructions,
159<code>SIGILL</code> typically indicates that the executable file is corrupted,
160or that you are trying to execute data.  Some common ways of getting
161into the latter situation are by passing an invalid object where a
162pointer to a function was expected, or by writing past the end of an
163automatic array (or similar problems with pointers to automatic
164variables) and corrupting other data on the stack such as the return
165address of a stack frame.
166
167        <p><code>SIGILL</code> can also be generated when the stack overflows, or when
168the system has trouble running the handler for a signal. 
169</p></blockquote></div>
170   <a name="index-illegal-instruction-2837"></a>
171<!-- signal.h -->
172<!-- ISO -->
173
174<div class="defun">
175&mdash; Macro: int <b>SIGSEGV</b><var><a name="index-SIGSEGV-2838"></a></var><br>
176<blockquote><p><a name="index-segmentation-violation-2839"></a>This signal is generated when a program tries to read or write outside
177the memory that is allocated for it, or to write memory that can only be
178read.  (Actually, the signals only occur when the program goes far
179enough outside to be detected by the system's memory protection
180mechanism.)  The name is an abbreviation for &ldquo;segmentation violation&rdquo;.
181
182        <p>Common ways of getting a <code>SIGSEGV</code> condition include dereferencing
183a null or uninitialized pointer, or when you use a pointer to step
184through an array, but fail to check for the end of the array.  It varies
185among systems whether dereferencing a null pointer generates
186<code>SIGSEGV</code> or <code>SIGBUS</code>. 
187</p></blockquote></div>
188
189<!-- signal.h -->
190<!-- BSD -->
191<div class="defun">
192&mdash; Macro: int <b>SIGBUS</b><var><a name="index-SIGBUS-2840"></a></var><br>
193<blockquote><p>This signal is generated when an invalid pointer is dereferenced.  Like
194<code>SIGSEGV</code>, this signal is typically the result of dereferencing an
195uninitialized pointer.  The difference between the two is that
196<code>SIGSEGV</code> indicates an invalid access to valid memory, while
197<code>SIGBUS</code> indicates an access to an invalid address.  In particular,
198<code>SIGBUS</code> signals often result from dereferencing a misaligned
199pointer, such as referring to a four-word integer at an address not
200divisible by four.  (Each kind of computer has its own requirements for
201address alignment.)
202
203        <p>The name of this signal is an abbreviation for &ldquo;bus error&rdquo;. 
204</p></blockquote></div>
205   <a name="index-bus-error-2841"></a>
206<!-- signal.h -->
207<!-- ISO -->
208
209<div class="defun">
210&mdash; Macro: int <b>SIGABRT</b><var><a name="index-SIGABRT-2842"></a></var><br>
211<blockquote><p><a name="index-abort-signal-2843"></a>This signal indicates an error detected by the program itself and
212reported by calling <code>abort</code>.  See <a href="Aborting-a-Program.html#Aborting-a-Program">Aborting a Program</a>. 
213</p></blockquote></div>
214
215<!-- signal.h -->
216<!-- Unix -->
217<div class="defun">
218&mdash; Macro: int <b>SIGIOT</b><var><a name="index-SIGIOT-2844"></a></var><br>
219<blockquote><p>Generated by the PDP-11 &ldquo;iot&rdquo; instruction.  On most machines, this is
220just another name for <code>SIGABRT</code>. 
221</p></blockquote></div>
222
223<!-- signal.h -->
224<!-- BSD -->
225<div class="defun">
226&mdash; Macro: int <b>SIGTRAP</b><var><a name="index-SIGTRAP-2845"></a></var><br>
227<blockquote><p>Generated by the machine's breakpoint instruction, and possibly other
228trap instructions.  This signal is used by debuggers.  Your program will
229probably only see <code>SIGTRAP</code> if it is somehow executing bad
230instructions. 
231</p></blockquote></div>
232
233<!-- signal.h -->
234<!-- BSD -->
235<div class="defun">
236&mdash; Macro: int <b>SIGEMT</b><var><a name="index-SIGEMT-2846"></a></var><br>
237<blockquote><p>Emulator trap; this results from certain unimplemented instructions
238which might be emulated in software, or the operating system's
239failure to properly emulate them. 
240</p></blockquote></div>
241
242<!-- signal.h -->
243<!-- Unix -->
244<div class="defun">
245&mdash; Macro: int <b>SIGSYS</b><var><a name="index-SIGSYS-2847"></a></var><br>
246<blockquote><p>Bad system call; that is to say, the instruction to trap to the
247operating system was executed, but the code number for the system call
248to perform was invalid. 
249</p></blockquote></div>
250
251   </body></html>
252