signal.texi

一个C源代码分析器

Floating underflow trap.  (Trapping on floating underflow is not
normally enabled.)
@comment signal.h
@comment BSD
@item FPE_DECOVF_TRAP
@vindex FPE_DECOVF_TRAP
Decimal overflow trap.  (Only a few machines have decimal arithmetic and
C never uses it.)
@ignore @c These seem redundant
@comment signal.h
@comment BSD
@item FPE_FLTOVF_FAULT
@vindex FPE_FLTOVF_FAULT
Floating overflow fault.
@comment signal.h
@comment BSD
@item FPE_FLTDIV_FAULT
@vindex FPE_FLTDIV_FAULT
Floating divide by zero fault.
@comment signal.h
@comment BSD
@item FPE_FLTUND_FAULT
@vindex FPE_FLTUND_FAULT
Floating underflow fault.
@end ignore
@end table

@comment signal.h
@comment ANSI
@deftypevr 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,
@code{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.

@code{SIGILL} can also be generated when the stack overflows, or when
the system has trouble running the handler for a signal.
@end deftypevr
@cindex illegal instruction

@comment signal.h
@comment ANSI
@deftypevr Macro int SIGSEGV
@cindex segmentation violation
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 @code{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
@code{SIGSEGV} or @code{SIGBUS}.
@end deftypevr

@comment signal.h
@comment BSD
@deftypevr Macro int SIGBUS
This signal is generated when an invalid pointer is dereferenced.  Like
@code{SIGSEGV}, this signal is typically the result of dereferencing an
uninitialized pointer.  The difference between the two is that
@code{SIGSEGV} indicates an invalid access to valid memory, while
@code{SIGBUS} indicates an access to an invalid address.  In particular,
@code{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''.
@end deftypevr
@cindex bus error

@comment signal.h
@comment ANSI
@deftypevr Macro int SIGABRT
@cindex abort signal
This signal indicates an error detected by the program itself and
reported by calling @code{abort}.  @xref{Aborting a Program}.
@end deftypevr

@comment signal.h
@comment Unix
@deftypevr Macro int SIGIOT
Generated by the PDP-11 ``iot'' instruction.  On most machines, this is
just another name for @code{SIGABRT}.
@end deftypevr

@comment signal.h
@comment BSD
@deftypevr 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 @code{SIGTRAP} if it is somehow executing bad
instructions.
@end deftypevr

@comment signal.h
@comment BSD
@deftypevr 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.
@end deftypevr

@comment signal.h
@comment Unix
@deftypevr 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.
@end deftypevr

@node Termination Signals
@subsection Termination Signals
@cindex program termination signals

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.

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.  (@xref{Termination in Handler}.)

The (obvious) default action for all of these signals is to cause the
process to terminate.

@comment signal.h
@comment ANSI
@deftypevr Macro int SIGTERM
@cindex termination signal
The @code{SIGTERM} signal is a generic signal used to cause program
termination.  Unlike @code{SIGKILL}, this signal can be blocked,
handled, and ignored.  It is the normal way to politely ask a program to
terminate.

The shell command @code{kill} generates @code{SIGTERM} by default.
@pindex kill
@end deftypevr

@comment signal.h
@comment ANSI
@deftypevr Macro int SIGINT
@cindex interrupt signal
The @code{SIGINT} (``program interrupt'') signal is sent when the user
types the INTR character (normally @kbd{C-c}).  @xref{Special
Characters}, for information about terminal driver support for
@kbd{C-c}.
@end deftypevr

@comment signal.h
@comment POSIX.1
@deftypevr Macro int SIGQUIT
@cindex quit signal
@cindex quit signal
The @code{SIGQUIT} signal is similar to @code{SIGINT}, except that it's
controlled by a different key---the QUIT character, usually
@kbd{C-\}---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.

@xref{Program Error Signals}, for information about core dumps.
@xref{Special Characters}, for information about terminal driver
support.

Certain kinds of cleanups are best omitted in handling @code{SIGQUIT}.
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} not to delete them, so that the user can
examine them in conjunction with the core dump.
@end deftypevr

@comment signal.h
@comment POSIX.1
@deftypevr Macro int SIGKILL
The @code{SIGKILL} 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.

This signal is usually 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} or @code{SIGTERM}.
If a process does not respond to any other termination signals, sending
it a @code{SIGKILL} signal will almost always cause it to go away.

In fact, if @code{SIGKILL} fails to terminate a process, that by itself
constitutes an operating system bug which you should report.

The system will generate @code{SIGKILL} for a process itself under some
unusual conditions where the program cannot possible continue to run
(even to run a signal handler).
@end deftypevr
@cindex kill signal

@comment signal.h
@comment POSIX.1
@deftypevr Macro int SIGHUP
@cindex hangup signal
The @code{SIGHUP} (``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 @ref{Control
Modes}.

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 @ref{Termination
Internals}.
@end deftypevr

@node Alarm Signals
@subsection Alarm Signals

These signals are used to indicate the expiration of timers.
@xref{Setting an Alarm}, for information about functions that cause
these signals to be sent.

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.

@comment signal.h
@comment POSIX.1
@deftypevr Macro int SIGALRM
This signal typically indicates expiration of a timer that measures real
or clock time.  It is used by the @code{alarm} function, for example.
@end deftypevr
@cindex alarm signal

@comment signal.h
@comment BSD
@deftypevr Macro int SIGVTALRM
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''.
@end deftypevr
@cindex virtual time alarm signal

@comment signal.h
@comment BSD
@deftypevr Macro int SIGPROF
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.
@end deftypevr
@cindex profiling alarm signal


@node Asynchronous I/O Signals
@subsection Asynchronous I/O Signals

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} to enable a particular file descriptior to generate
these signals (@pxref{Interrupt Input}).  The default action for these
signals is to ignore them.

@comment signal.h
@comment BSD
@deftypevr Macro int SIGIO
@cindex input available signal
@cindex output possible signal
This signal is sent when a file descriptor is ready to perform input
or output.

On most operating systems, terminals and sockets are the only kinds of
files that can generate @code{SIGIO}; other kinds, including ordinary
files, never generate @code{SIGIO} even if you ask them to.

In the GNU system @code{SIGIO} will always be generated properly 
if you successfully set asynchronous mode with @code{fcntl}.
@end deftypevr

@comment signal.h
@comment BSD
@deftypevr Macro int SIGURG
@cindex urgent data signal
This signal is sent when ``urgent'' or out-of-band data arrives on a
socket.  @xref{Out-of-Band Data}.
@end deftypevr

@comment signal.h
@comment SVID
@deftypevr Macro int SIGPOLL
This is a System V signal name, more or less similar to @code{SIGIO}.
It is defined only for compatibility.
@end deftypevr

@node Job Control Signals
@subsection Job Control Signals
@cindex job control signals

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.

You should generally leave these signals alone unless you really
understand how job control works.  @xref{Job Control}.

@comment signal.h
@comment POSIX.1
@deftypevr Macro int SIGCHLD
@cindex child process signal
This signal is sent to a parent process whenever one of its child
processes terminates or stops.

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} or
@code{waitpid} (@pxref{Process Completion}), whether your new handler
applies to those processes or not depends on the particular operating
system.
@end deftypevr

@comment signal.h
@comment SVID
@deftypevr Macro int SIGCLD
This is an obsolete name for @code{SIGCHLD}.
@end deftypevr

@comment signal.h
@comment POSIX.1
@deftypevr Macro int SIGCONT
@cindex continue signal
You can send a @code{SIGCONT} signal to a process to make it continue.
This signal is special---it always makes the process continue if it is
stopped, before the signal is delivered.  The default behavior is to do
nothing else.  You cannot block this signal.  You can set a handler, but