library_21.html

Linux程序员的工作手册

<DD>Integer division by zero.
<A NAME="IDX1473"></A>
<DT><CODE>FPE_SUBRNG_TRAP</CODE>
<DD>Subscript-range (something that C programs never check for).
<A NAME="IDX1474"></A>
<DT><CODE>FPE_FLTOVF_TRAP</CODE>
<DD>Floating overflow trap.
<A NAME="IDX1475"></A>
<DT><CODE>FPE_FLTDIV_TRAP</CODE>
<DD>Floating/decimal division by zero.
<A NAME="IDX1476"></A>
<DT><CODE>FPE_FLTUND_TRAP</CODE>
<DD>Floating underflow trap.  (Trapping on floating underflow is not
normally enabled.)
<A NAME="IDX1477"></A>
<DT><CODE>FPE_DECOVF_TRAP</CODE>
<DD>Decimal overflow trap.  (Only a few machines have decimal arithmetic and
C never uses it.)
</DL>
<P>
<A NAME="IDX1478"></A>
<U>Macro:</U> int <B>SIGILL</B><P>
The name of this signal is derived from "illegal instruction"; it
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.
<A NAME="IDX1479"></A>
<P>
<A NAME="IDX1480"></A>
<A NAME="IDX1481"></A>
<U>Macro:</U> int <B>SIGSEGV</B><P>
This signal is generated when a program tries to read or write outside
the memory that is allocated for it.  (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>
The most common way of getting a <CODE>SIGSEGV</CODE> condition is by
dereferencing a null or uninitialized pointer.  A null pointer refers to
the address 0, and most operating systems make sure this address is
always invalid precisely so that dereferencing a null pointer will cause
<CODE>SIGSEGV</CODE>.  (Some operating systems place valid memory at address
0, and dereferencing a null pointer does not cause a signal on these
systems.)  As for uninitialized pointer variables, they contain random
addresses which may or may not be valid.
<P>
Another common way of getting into a <CODE>SIGSEGV</CODE> situation is when
you use a pointer to step through an array, but fail to check for the
end of the array.
<P>
<A NAME="IDX1482"></A>
<U>Macro:</U> int <B>SIGBUS</B><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".
<A NAME="IDX1483"></A>
<P>
<A NAME="IDX1484"></A>
<A NAME="IDX1485"></A>
<U>Macro:</U> int <B>SIGABRT</B><P>
This signal indicates an error detected by the program itself and
reported by calling <CODE>abort</CODE>.  See section <A HREF="library_22.html#SEC399" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_22.html#SEC399">Aborting a Program</A>.
<P>
<A NAME="IDX1486"></A>
<H3><A NAME="SEC337" HREF="library_toc.html#SEC337" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_toc.html#SEC337">Termination Signals</A></H3>
<P>
These signals are all used to tell a process to terminate, in one way
or another.  They have different names because they're used for slightly
different purposes, and programs might want to handle them differently.
<P>
The reason for handling these signals is usually so your program can
tidy up as appropriate before actually terminating.  For example, you
might want to save state information, delete temporary files, or restore
the previous terminal modes.  Such a 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 section <A HREF="library_21.html#SEC353" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_21.html#SEC353">Handlers That Terminate the Process</A>.)
<P>
The (obvious) default action for all of these signals is to cause the
process to terminate.
<P>
<A NAME="IDX1487"></A>
<A NAME="IDX1488"></A>
<U>Macro:</U> int <B>SIGHUP</B><P>
The <CODE>SIGHUP</CODE> ("hang-up") signal is used to report that the user's
terminal is disconnected, perhaps because a network or telephone
connection was broken.  For more information about this, see section <A HREF="library_16.html#SEC278" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_16.html#SEC278">Control Modes</A>.
<P>
This signal is also used to report the termination of the controlling
process on a terminal to jobs associated with that session; this
termination effectively disconnects all processes in the session from
the controlling terminal.  For more information, see section <A HREF="library_22.html#SEC400" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_22.html#SEC400">Termination Internals</A>.
<P>
<A NAME="IDX1489"></A>
<A NAME="IDX1490"></A>
<U>Macro:</U> int <B>SIGINT</B><P>
The <CODE>SIGINT</CODE> ("program interrupt") signal is sent when the user
types the INTR character (normally <KBD>C-c</KBD>).  See section <A HREF="library_16.html#SEC281" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_16.html#SEC281">Special Characters</A>, for information about terminal driver support for
<KBD>C-c</KBD>.
<P>
<A NAME="IDX1491"></A>
<A NAME="IDX1492"></A>
<A NAME="IDX1493"></A>
<U>Macro:</U> int <B>SIGQUIT</B><P>
The <CODE>SIGQUIT</CODE> signal is similar to <CODE>SIGINT</CODE>, except that it's
controlled by a different key--the QUIT character, usually
<KBD>C-\</KBD>---and produces a core dump when it terminates the process,
just like a program error signal.  You can think of this as a
program error condition "detected" by the user.
<P>
See section <A HREF="library_21.html#SEC336" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_21.html#SEC336">Program Error Signals</A>, for information about core dumps.
See section <A HREF="library_16.html#SEC281" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_16.html#SEC281">Special Characters</A>, for information about terminal driver
support.
<P>
Certain kinds of cleanups are best omitted in handling <CODE>SIGQUIT</CODE>.
For example, if the program creates temporary files, it should handle
the other termination requests by deleting the temporary files.  But it
is better for <CODE>SIGQUIT</CODE> not to delete them, so that the user can
examine them in conjunction with the core dump.
<P>
<A NAME="IDX1494"></A>
<A NAME="IDX1495"></A>
<U>Macro:</U> int <B>SIGTERM</B><P>
The <CODE>SIGTERM</CODE> signal is a generic signal used to cause program
termination.  Unlike <CODE>SIGKILL</CODE>, this signal can be blocked,
handled, and ignored.
<P>
The shell command <CODE>kill</CODE> generates <CODE>SIGTERM</CODE> by default.
<A NAME="IDX1496"></A>
<P>
<A NAME="IDX1497"></A>
<U>Macro:</U> int <B>SIGKILL</B><P>
The <CODE>SIGKILL</CODE> signal is used to cause immediate program termination.
It cannot be handled or ignored, and is therefore always fatal.  It is
also not possible to block this signal.
<P>
This signal is generated only by explicit request.  Since it cannot be
handled, you should generate it only as a last resort, after first
trying a less drastic method such as <KBD>C-c</KBD> or <CODE>SIGTERM</CODE>.  If a
process does not respond to any other termination signals, sending it a
<CODE>SIGKILL</CODE> signal will almost always cause it to go away.
<P>
In fact, if <CODE>SIGKILL</CODE> fails to terminate a process, that by itself
constitutes an operating system bug which you should report.
<A NAME="IDX1498"></A>
<P>
<H3><A NAME="SEC338" HREF="library_toc.html#SEC338" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_toc.html#SEC338">Alarm Signals</A></H3>
<P>
These signals are used to indicate the expiration of timers.
See section <A HREF="library_19.html#SEC321" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_19.html#SEC321">Setting an Alarm</A>, for information about functions that cause
these signals to be sent.
<P>
The default behavior for these signals is to cause program termination.
This default is rarely useful, but no other default would be useful;
most of the ways of using these signals would require handler functions
in any case.
<P>
<A NAME="IDX1499"></A>
<U>Macro:</U> int <B>SIGALRM</B><P>
This signal typically indicates expiration of a timer that measures real
or clock time.  It is used by the <CODE>alarm</CODE> function, for example.
<A NAME="IDX1500"></A>
<P>
<A NAME="IDX1501"></A>
<U>Macro:</U> int <B>SIGVTALRM</B><P>
This signal typically indicates expiration of a timer that measures CPU
time used by the current process.  The name is an abbreviation for
"virtual time alarm".
<A NAME="IDX1502"></A>
<P>
<A NAME="IDX1503"></A>
<U>Macro:</U> int <B>SIGPROF</B><P>
This signal is typically indicates expiration of a timer that measures
both CPU time used by the current process, and CPU time expended on 
behalf of the process by the system.  Such a timer is used to implement
code profiling facilities, hence the name of this signal.
<A NAME="IDX1504"></A>
<P>
<H3><A NAME="SEC339" HREF="library_toc.html#SEC339" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_toc.html#SEC339">Asynchronous I/O Signals</A></H3>
<P>
The signals listed in this section are used in conjunction with
asynchronous I/O facilities.  You have to take explicit action by
calling <CODE>fcntl</CODE> to enable a particular file descriptior to generate
these signals (see section <A HREF="library_12.html#SEC186" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_12.html#SEC186">Interrupt-Driven Input</A>).  The default action for these
signals is to ignore them.
<P>
<A NAME="IDX1505"></A>
<A NAME="IDX1506"></A>
<A NAME="IDX1507"></A>
<U>Macro:</U> int <B>SIGIO</B><P>
This signal is sent when a file descriptor is ready to perform input
or output.
<P>
On most operating systems, terminals and sockets are the only kinds of
files that can generate <CODE>SIGIO</CODE>; other kinds, including ordinary
files, never generate <CODE>SIGIO</CODE> even if you ask them to.
<P>
<A NAME="IDX1508"></A>
<A NAME="IDX1509"></A>
<U>Macro:</U> int <B>SIGURG</B><P>
This signal is sent when "urgent" or out-of-band data arrives on a
socket.  See section <A HREF="library_15.html#SEC255" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_15.html#SEC255">Out-of-Band Data</A>.
<P>
<A NAME="IDX1510"></A>
<H3><A NAME="SEC340" HREF="library_toc.html#SEC340" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_toc.html#SEC340">Job Control Signals</A></H3>
<P>
These signals are used to support job control.  If your system
doesn't support job control, then these macros are defined but the
signals themselves can't be raised or handled.
<P>
You should generally leave these signals alone unless you really
understand how job control works.  See section <A HREF="library_24.html#SEC411" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_24.html#SEC411">Job Control</A>.
<P>
<A NAME="IDX1511"></A>
<A NAME="IDX1512"></A>
<U>Macro:</U> int <B>SIGCHLD</B><P>
This signal is sent to a parent process whenever one of its child
processes terminates or stops.
<P>
The default action for this signal is to ignore it.  If you establish a
handler for this signal while there are child processes that have
terminated but not reported their status via <CODE>wait</CODE> or
<CODE>waitpid</CODE> (see section <A HREF="library_23.html#SEC407" tppabs="http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_23.html#SEC407">Process Completion</A>), whether your new handler
applies to those processes or not depends on the particular operating
system.
<P>
<A NAME="IDX1513"></A>
<A NAME="IDX1514"></A>
<U>Macro:</U> int <B>SIGCONT</B><P>
You can send a <CODE>SIGCONT</CODE> signal to a process to make it continue.
The default behavior for this signal is to make the process continue if
it is stopped, and to ignore it otherwise.
<P>
Most programs have no reason to handle <CODE>SIGCONT</CODE>; they simply
resume execution without realizing they were ever stopped.  You can use
a handler for <CODE>SIGCONT</CODE> to make a program do something special when
it is stopped and continued--for example, to reprint a prompt when it
is suspended while waiting for input.
<P>
<A NAME="IDX1515"></A>
<U>Macro:</U> int <B>SIGSTOP</B><P>
The <CODE>SIGSTOP</CODE> signal stops the process.  It cannot be handled,
ignored, or blocked.
<A NAME="IDX1516"></A>
<P>
<A NAME="IDX1517"></A>
<U>Macro:</U> int <B>SIGTSTP</B><P>
The <CODE>SIGTSTP</CODE> signal is an interactive stop signal.  Unlike
<CODE>SIGSTOP</CODE>, this signal can be handled and ignored.  
<P>
Your program should handle this signal if you have a special need to
leave files or system tables in a secure state when a process is