Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
signal(5)		      File Formats Manual		     signal(5)

NAME
       signal: signal.h	- description of signals

SYNOPSIS
DESCRIPTION
       The  header defines the following symbolic constants, each of which ex-
       pands to	a distinct constant expression of the type:

       whose value matches no declarable function.

	      Request for default signal handling.

	      Return value from
			     in	case of	error.

	      Request that signal be held.

	      Request that signal be ignored.

       The following data types	are defined through

	      sig_atomic_t   Integral type of an object	that can  be  accessed
			     as	 an  atomic  entity,  even  in the presence of
			     asynchronous interrupts

	      sigset_t	     Integral or structure type	of an object  used  to
			     represent sets of signals.

	      pid_t	     As	described in

       This  header  also declares the constants that are used to refer	to the
       signals that occur in the system. Signals defined here begin  with  the
       letters Each of the signals have	distinct positive integral values. The
       value 0 is reserved for use as the null signal  (see  kill(2)).	 Addi-
       tional implementation-dependent signals may occur in the	system.

       The following signals are supported on all implementations (default ac-
       tions are explained below the table):

			  Default
	      Signal	  Action    Description

	      SIGABRT	  ii	    Process abort signal.
	      SIGALRM	  i	    Alarm clock.
	      SIGFPE	  ii	    Erroneous arithmetic operation.
	      SIGHUP	  i	    Hangup.
	      SIGILL	  ii	    Illegal instruction.
	      SIGINT	  i	    Terminal interrupt signal.
	      SIGKILL	  i	    Kill (cannot be caught or ignored).
	      SIGPIPE	  i	    Write on a pipe with no one	to read	it.
	      SIGQUIT	  ii	    Terminal quit signal.
	      SIGSEGV	  ii	    Invalid memory reference.
	      SIGTERM	  i	    Termination	signal.
	      SIGUSR1	  i	    User-defined signal	1.
	      SIGUSR2	  i	    User-defined signal	2.
	      SIGCHLD	  iii	    Child process terminated or	stopped.
	      SIGCONT	  v	    Continue executing,	if stopped.
	      SIGSTOP	  iv	    Stop executing (cannot be caught or	ignored).
	      SIGTSTP	  iv	    Terminal stop signal.
	      SIGTTIN	  iv	    Background process attempting read.
	      SIGTTOU	  iv	    Background process attempting write.

	      SIGBUS	  ii	    Bus	error.
	      SIGPOLL	  i	    Pollable event.
	      SIGPROF	  i	    Profiling timer expired.
	      SIGSYS	  ii	    Bad	system call.
	      SIGTRAP	  ii	    Trace/breakpoint trap.
	      SIGURG	  iii	    High bandwidth data	is available at	a socket.
	      SIGVTALRM	  i	    Virtual timer expired.
	      SIGXCPU	  ii	    CPU	time limit exceeded.
	      SIGXFSZ	  ii	    File size limit exceeded.
	      SIGRTMIN	  i	    First realtime signal.
	      SIGRTMAX	  i	    Last realtime signal.

       The macros and evaluate to integral expressions,	and  specify  a	 range
       that includes at	least signal numbers that are reserved for application
       use and for which the realtime signal  extensions  are  supported  (see
       sigaction(2)).

       The default actions are as follows:

	      i		Abnormal  termination  of  the process.	The process is
			terminated with	all the	consequences  of  except  that
			the status is made available to	and indicates abnormal
			termination by the specified signal.

	      ii	Abnormal termination of	the process. Additionally, im-
			plementation-dependent	abnormal  termination actions,
			such as	creation of a core file, may occur.

	      iii	Ignore the signal.

	      iv	Stop the process.

	      v		Continue the process, if it is stopped;	otherwise  ig-
			nore the signal.

       The header provides a declaration of struct including at	least the fol-
       lowing members:

       void			    (*sa_handler)(int)	 what to do  on	 re-
							 ceipt of signal

       sigset_t			    sa_mask		 set  of  signals to
							 be  blocked  during
							 execution   of	 the
							 signal	    handling
							 function

       int			    sa_flags		 special flags

       void (*)			    sa_sigaction	 pointer to signal
       (int, siginfo_t *, void *)			 handler function

       The  storage occupied by	sa_handler and sa_sigaction may	overlap, and a
       portable	program	must not use both simultaneously.

       The following are declared as constants:

	      Do not generate	       when children stop.

	      The resulting set	is the union of	the current set	and the
				       signal set pointed to by	 the  argument
				       set.

	      The resulting set	is the intersection of the current set
				       and  the	 complement  of	the signal set
				       pointed to by the argument set.

	      The resulting set	is the signal set pointed to by	the argument
				       set.  Causes signal delivery  to	 occur
				       on an alternate stack.

	      Causes signal dispositions to be set to
				       on entry	to signal handlers.

	      Causes certain functions to become restartable.

	      Causes extra information to be passed to signal handlers at the
				       time of receipt of a signal.

	      Causes  implementations  not to create zombie processes on child
	      death.

	      Causes signal not	to be automatically blocked on entry to
				       signal handler.

	      Process is executing on an alternate signal stack.

	      Alternate	signal stack is	disabled.

	      Minimum stack size for a signal handler.

	      Default size in bytes for	the alternate signal stack.

       The structure is	defined	through	as described in

       The header defines the type as a	structure that includes	at  least  the
       following members:

	      void     *ss_sp	  stack	base or	pointer
	      size_t   ss_size	  stack	size
	      int      ss_flags	  flags

       The  header  defines the	structure that includes	at least the following
       members:

	      int    ss_onstack	  non-zero when	signal stack is	in use
	      void   *ss_sp	  signal stack pointer

       The header defines the structure	that includes at least	the  following
       members:

	      int	     sigev_notify   Notification type
	      int	     sigev_signo    Signal number
	      union sigval   sigev_value    Signal value.

       The  sigev_notify  member  specifies  the notification mechanism	to use
       when an asynchronous event occurs. The following	values are defined for
       the sigev_notify	member:

	      No asynchronous notification will	be delivered when the
				       event of	interest occurs.

	      The signal specified in  sigev_signo  will  be generated for the
				       process when the	event of interest  oc-
				       curs. If	is set for that	signal number,
				       then the	signal will be queued  to  the
				       process,	 and  the  value  specified in
				       sigev_value  will  be  the  sigev_value
				       component  of the generated signal.  If
				       is not set for that signal  number,  it
				       is  unspecified	whether	 the signal is
				       queued, and  what  value,  if  any,  is
				       sent.

       The  sigev_signo	 member	 specifies  the	 signal	 to be generated.  The
       sigev_value member is the application-defined value to be passed	to the
       signal-catching	function  at  the time of the signal delivery or to be
       returned	at signal acceptance as	the si_value member of	the  siginfo_t
       structure.

       The header defines as a union that includes at least the	following mem-
       bers:

	      int      sival_int   Integer signal value
	      void *   sival_ptr   Pointer signal value.

       The header defines the type as a	structure that includes	at  least  the
       following members:

	      int	     si_signo	 signal	number
	      int	     si_errno	 if  non-zero,	an value associ-
					 ated with this	signal,	 as  de-
					 fined in
	      int	     si_code	 signal	code
	      union sigval   si_value	 signal	value
	      id_t	     si_pid	 sending process ID
	      uid_t	     si_uid	 real user ID of sending process
	      void	     *si_addr	 address of faulting instruction
	      int	     si_status	 exit value or signal
	      long	     si_band	 band event for	SIGPOLL

       The si_code member contains a code identifying the cause	of the signal.
       The following values are	defined	for si_code:

	      The signal was sent by   The si_code may be set to also  if  the
				       signal was sent by or similar functions
				       that are	provided as implementation ex-
				       tensions	of

	      The signal was sent by

	      The signal was generated by the expiration of
				       a timer set by

	      The signal was generated by the completion of
				       an asynchronous I/O request.

	      The signal was generated by the arrival of
				       a message on an empty message queue.

       If  the	signal	was  not  generated  by	one of the functions or	events
       listed above, the si_code will  be  set	to  an	implementation-defined
       value (see below) that is not equal to any of the values	defined	above.

       If  si_code  is	one  of	or then	si_value will contain the application-
       specified signal	value.	Otherwise, the contents	of si_value are	 unde-
       fined.

       The  macros specified in	the Code column	of the following table are de-
       fined for use as	values of si_code that are signal-specific reasons why
       the signal was generated.

	      Signal	Code		Reason

	      SIGILL	ILL_ILLOPC	illegal	opcode
			ILL_ILLOPN	illegal	operand
			ILL_ILLADR	illegal	addressing mode

			ILL_ILLTRP	illegal	trap
			ILL_PRVOPC	privileged opcode
			ILL_PRVREG	privileged register
			ILL_COPROC	coprocessor error
			ILL_BADSTK	internal stack error

	      SIGFPE	FPE_INTDIV	integer	divide by zero
			FPE_INTOVF	integer	overflow
			FPE_FLTDIV	floating point divide by zero
			FPE_FLTOVF	floating point overflow
			FPE_FLTUND	floating point underflow
			FPE_FLTRES	floating point inexact result
			FPE_FLTINV	invalid	floating point operation
			FPE_FLTSUB	subscript out of range

	      SIGSEGV	SEGV_MAPERR	address	not mapped to object
			SEGV_ACCERR	invalid	permissions for	mapped object

	      SIGBUS	BUS_ADRALN	invalid	address	alignment
			BUS_ADRERR	non-existent physical address
			BUS_OBJERR	object specific	hardware error

	      SIGTRAP	TRAP_BRKPT	process	breakpoint
			TRAP_TRACE	process	trace trap

	      SIGCHLD	CLD_EXITED	child has exited
			CLD_KILLED	child has terminated abnormally	and
					did not	create a core file
			CLD_DUMPED	child has terminated and created a core	file
			CLD_KILLED	child was killed
			CLD_DUMPED	child has terminated abnormally
			CLD_TRAPPED	traced child has trapped
			CLD_STOPPED	child has stopped
			CLD_CONTINUED	stopped	child has continued

	      SIGPOLL	POLL_IN		data input available
			POLL_OUT	output buffers available
			POLL_MSG	input message available
			POLL_ERR	I/O error
			POLL_PRI	high priority input available
			POLL_HUP	device disconnected

       Implementations	may  support additional	si_code	values not included in
       this list, may generate values included	in  this  list	under  circum-
       stances other than those	described in this list,	and may	contain	exten-
       sions or	limitations that prevent some values from being	generated. Im-
       plementations  will  not	 generate  a different value from the ones de-
       scribed in this list for	circumstances described	in this	list.

       In addition, the	following signal-specific information will  be	avail-
       able:

       Signal	 Member		  Value

       SIGILL	 void *	si_addr	  address of faulting instruction
       SIGFP
       SIGSEGV	 void *	si_addr	  address of faulting memory reference
       SIGBUS
       SIGCHLD	 pid_t si_pid	  child	process	ID
		 int si_status	  exit value or	signal
		 uid_t si_uid	  real	user  ID  of  the process that
				  sent the signal
       SIGPOLL	 long si_band	  band event for or

       For some	implementations, the value of si_addr may be inaccurate.

       The following are declared as functions and  may	 also  be  defined  as
       macros:

APPLICATION USAGE
   Threads Considerations
       The following summarizes	the signal model for threads:

	      A	 signal	mask which specifies the signals blocked from delivery
	      is associated with each thread.

	      The signal disposition, catch/ignore/default, is a  process  at-
	      tribute and is shared by all threads in the process.

	      If the signal action for a signal	specifies termination, stop or
	      continue,	all threads within the process are terminated, stopped
	      or  continued,  respectively.   This  is	the case regardless of
	      whether the signal was directed at the  process  or  a  specific
	      thread within the	process.

	      Signals  which  are  generated  by some action associated	with a
	      particular thread, such as an invalid pointer dereference,  will
	      be  delivered  to	 the thread which caused the generation	of the
	      signal.  These signals are referred to as	 synchronously	gener-
	      ated signals.

	      Signals  that are	posted to the process by kill(2) or some asyn-
	      chronous event such as terminal activity will  be	 delivered  to
	      exactly  one thread in the process which does not	block delivery
	      of the signal; if	there is more than one eligible	thread,	 which
	      thread  the  signal is delivered to may not be able to be	deter-
	      mined by an application.	If all threads in  the	process	 block
	      the signal, then the signal remains pending on the process until
	      a	thread unblocks	the signal, issues a call for  the  signal  or
	      sets the signal disposition to ignore the	signal.	 These signals
	      are referred to as asynchronously	generated signals.

	      A	thread can post	a signal to a particular thread	 in  the  same
	      process using If the thread which	the signal is posted to	blocks
	      delivery of the  signal,	the  signal  remains  pending  on  the
	      thread.

	      The  function  returns  a	union of the set of signals pending on
	      the process and on the calling thread.

	      Each thread may define an	alternate signal handling stack.

   Threadsafe Considerations
       Refer to	thread_safety(5) for a list of libc and	libpthread  interfaces
       which are not thread-safe, cancellation points, cancel safe, async sig-
       nal safe, and async cancel safe.

   LWP Considerations
       A signal	mask which specifies the signals blocked from delivery is  as-
       sociated	with each Lightweight Process (LWP).

       The  signal  disposition,  catch/ignore/default,	is a process attribute
       and is shared by	all LWPs in the	process.

       An LWP can post a signal	to a particular	LWP in the same	process	 using
       If the thread which the signal is posted	to blocks delivery of the sig-
       nal, the	signal remains pending on the thread.

       Each LWP	may define an alternate	signal handling	stack.

SEE ALSO
       alarm(2), ioctl(2), kill(2),  sigaction(2),  sigaltstack(2),  siginter-
       rupt(2),	signal(2), sigpending(2), sigprocmask(2), sigstack(2), sigsus-
       pend(2),	sigwait(2), thread_safety(5), wait(2), waitid(2).

CHANGE HISTORY
       First released in Issue 1.

Issue 4
       The following changes are  incorporated	for  alignment	with  the  ISO
       POSIX-1 standard:

	      o	 The function declarations in this header are expanded to full
		 ISO C prototypes.

	      o	 The DESCRIPTION section is changed:

		 -  to define the type sig_atomic_t

		 -  to define the syntax of signal names and functions

		 -  to combine the two tables of constants

		 -  is no longer limited  to  floating-point  exceptions,  but
		    covers all erroneous arithmetic operations.

       The following change is incorporated for	alignment with the ISO C stan-
       dard:

	      o	 The function is added to the list of  functions  declared  in
		 this header.

       Other changes are incorporated as follows:

	      o	 A reference to	is added for the definition of pid_t.  This is
		 marked	as an extension.

	      o	 In the	list of	signals	starting with  the  statement  "but  a
		 system	 not  supporting the job control option	is not obliged
		 to support the	functionality of these	signals"  is  removed.
		 This  is because job control is defined as mandatory on Issue
		 4 conforming implementations.

	      o	 Reference to  implementation-dependent	 abnormal  termination
		 routines,  such as creation of	a core file, in	item ii	in the
		 defaults action list is marked	as an extension.

Issue 4, Version 2
       The following changes are incorporated for X/OPEN UNIX conformance:

	      o	 The and signals are added to the list of signals that will be
		 supported on all conforming implementations.

	      o	 The sa_sigaction member is added to the structure, and	a note
		 is added that the storage used	by sa_handler and sa_sigaction
		 may overlap.

	      o	 The  and  constants  are  defined. The	and structures are de-
		 fined.

	      o	 Definitions are given for the and types.

	      o	 A table is provided listing macros that are defined  as  sig-
		 nal-specific  reasons why a signal was	generated. Signal-spe-
		 cific additional information is specified.

	      o	 The and functions are added to	the list of functions declared
		 in this header.

signal(5)		      File Formats Manual		     signal(5)

				  HP-UX	EXTENSIONS

DESCRIPTION
       HP-UX supports multiple signal interfaces (see sigaction(2), signal(2),
       sigvector(2), bsdproc(3C), and sigset(3C))  that	 allow	a  process  to
       specify the action taken	upon receipt of	a signal. All supported	signal
       interfaces require specification	of a signal, as	designated by the Name
       and Number shown	below.	Signal specification can be any	of the follow-
       ing except or which cannot be caught or ignored:

	Name	   Number   Notes     Meaning
	---------------------------------------------------------------------
	SIGILL	     04	    A,B,C     illegal instruction
	SIGTRAP	     05	    A,B,C     trace trap
	SIGIOT	     06	    A,B	      software generated signal
	SIGEMT	     07	    A,B	      software generated signal
	SIGFPE	     08	    A,B	      floating point exception
	SIGKILL	     09	    A,D,E,F   kill
	SIGCLD	     l8	    G	      death of a child (see WARNINGS below)
	SIGPWR	     19	    C,G	      power fail (see WARNINGS below)
	SIGIO	     22	    G	      asynchronous I/O signal; see select(2)
	SIGWINCH     23	    G	      window size change; see termio(7)
	SIGURG	     29	    G	      urgent data arrived on an	I/O channel
	SIGLOST	     30	    A	      file lock	lost (NFS file locking)
	---------------------------------------------------------------------

       The letters in the Notes	column in the table above indicate the	action
       taken  when  the	 signal	is received, and any special conditions	on its
       use:

	      A	      The default action is to terminate the process.

	      B	      The default action of terminating	the process also  gen-
		      erates a core image file if possible.

	      C	      The  action  is  not reset to SIG_DFL before calling the
		      signal-catching function.

	      D	      The signal cannot	be ignored.

	      E	      The signal cannot	be caught.

	      F	      The signal will not be held off from a stopped process.

	      G	      The default action is to ignore the signal.

	      H	      The default action is to stop the	process.

       All signal interfaces allow specification of an action that  determines
       what  to	do upon	the receipt of a signal, and should be one of the fol-
       lowing:

	      Execute the default action,
			  which	varies depending on the	 signal	 as  described
			  above:

			       A    Terminate  the  receiving process with all
				    of the consequences	outlined in exit(2).

			       B    If following conditions are	met,  generate
				    a  core  image  file  (see core(4))	in the
				    current working directory of the receiving
				    process:

					 o  The	effective user ID and the real
					    user ID of the  receiving  process
					    are	equal.

					 o  The	 effective  group  ID  and the
					    real group	ID  of	the  receiving
					    process are	equal.

					 o  A regular file named core does not
					    exist and can be created,  or  ex-
					    ists and is	writable.

				    If the file	is created, it has the follow-
				    ing	properties:

					 o  The	file mode is 0666, modified by
					    the	 file  creation	mode mask (see
					    umask(2)).

					 o  The	file user ID is	equal  to  the
					    effective user ID of the receiving
					    process.

					 o  The	file group ID is equal to  the
					    effective  group ID	of the receiv-
					    ing	process.

			       G    Ignore the signal.	Do  not	 terminate  or
				    stop the receiving process.

			       H    Stop   the	receiving  process.   While  a
				    process is stopped,	any additional signals
				    sent  to  the  process are suspended until
				    the	process	 is  restarted	(except	 those
				    marked  with  Note F above,	which are pro-
				    cessed immediately).   However,  when  the
				    process  is	restarted, pending signals are
				    processed.	When a process that is	in  an
				    orphaned  process  group (see glossary(9))
				    receives a or signal, the process  is  not
				    stopped  because  a	process	in an orphaned
				    process group is not allowed to stop.  In-
				    stead,  a  signal  is sent to the process,
				    and	the or is discarded.

	      Ignore the signal.
			  When one of the supported signal interface  routines
			  is  used to set the action of	a signal to and	an in-
			  stance of the	signal is pending, the pending	signal
			  is cleared.

			       D    Signals marked with	Note D above cannot be
				    ignored.

	      address	  Catch	the signal.
			  Upon receipt of the signal, if is used  to  set  the
			  action,  reset  the  action for the signal caught to
			  (except signals marked with Note C).	Then, call the
			  signal-catching  function  to	 which address points,
			  and resume executing the receiving  process  at  the
			  point	 where	it  was	interrupted.  Signal interface
			  routines other than normally do not reset the	action
			  for  the  signal caught.  However, and provide a way
			  of specifying	this  behavior	(see  sigaction(2)  or
			  sigvector(2)).

			  The signal-catching function is called with the fol-
			  lowing three parameters:

			       sig     The signal number.

			       code    A word of information usually  provided
				       by the hardware.

			       scp     A   pointer  to	the  machine-dependent
				       structure sigcontext defined in

			  Depending on the value of  sig,  code	 can  be  zero
			  and/or  scp  can  be NULL.  The meanings of code and
			  scp and the conditions  determining  when  they  are
			  other	than zero or NULL are implementation-dependent
			  (see DEPENDENCIES below).  It	is possible  for  code
			  to always be zero, and scp to	always be NULL.

			  The  pointer scp is valid only during	the context of
			  the signal-catching function.

			  Optional parameters can be omitted from the  signal-
			  catching  function parameter list, in	which case the
			  signal-catching function is exactly compatible  with
			  UNIX	System	V.  Truly portable software should not
			  use the optional parameters in signal-catching  rou-
			  tines.

			  Upon	return	from the signal-catching function, the
			  receiving process resumes  execution	at  the	 point
			  where	it was interrupted.

			  When a signal	is caught during the execution of sys-
			  tem calls such as or on a slow  device  (such	 as  a
			  terminal, but	not a file), during a system call or a
			  system call that does	not return immediately because
			  a  previously	 stopped or zombie process already ex-
			  ists,	the signal-catching function is	 executed  and
			  the  interrupted  system  call  returns  a -1	to the
			  calling process with set to EINTR.

	      C	   If the signal is marked with	Note C above,  the  action  is
		   not	reset  to before calling the signal-catching function.
		   Furthermore,	the action is not reset	if any	signal	inter-
		   face	 routine  other	 than was used to set the action.  See
		   the description of signal catching above.

	      E	   If the signal is marked with	Note E above, the signal  can-
		   not be caught.

       When  any  stop	signal is generated for	a process, pending signals for
       that process are	 discarded.   Conversely,  when	 is  generated	for  a
       process,	all pending stop signals for that process are discarded.  When
       is generated for	a stopped process, the process is continued,  even  if
       the  signal  is blocked or ignored.  If is blocked and not ignored, the
       process remains pending until it	is either unblocked or a  stop	signal
       is generated.

       Note:  When  any	 stop  signal  (SIGSTOP,  SIGTSTP, SIGTIN, SIGTTOU) is
       posted to threads created with process contention scope,	using  pending
       SIGCONT	signals	 may  not  be  discarded.   Similarly, when SIGCONT is
       posted to threads created with process contention scope,	using  pending
       stop  signals may not be	discarded.  However, stop and continue signals
       posted to threads created with system contention	scope, using will con-
       tinue to	adhere to the semantics	described in the preceding paragraph.

       is  sent	by the system if an system call	is unsuccessful	and the	origi-
       nal program has already been deleted.

WARNINGS
       The signals and behave differently than those described above.

       The actions for these signals is	modified as follows:

	      Setting the action
			     for to in a parent	process	prevents exiting chil-
			     dren  of the calling process from creating	a zom-
			     bie process.  If the parent process executes  the
			     function, the calling process blocks until	all of
			     the child processes of the	calling	processes ter-
			     minate.   The function then returns a value of -1
			     with set to ECHILD	(see wait(2)).

			     If	one of the signal interface routines  is  used
			     to	 set  the  action for to be caught (that is, a
			     function address is supplied) in a	 process  that
			     currently	has  terminated	 (zombie)  children, a
			     signal is delivered to the	parent process immedi-
			     ately.  Thus, if the signal-catching function re-
			     installs itself, the apparent effect is that  any
			     signals  received	due  to	 the death of children
			     while the function	is executing  are  queued  and
			     the signal-catching function is continually reen-
			     tered until the queue is empty.   Note  that  the
			     function  must reinstall itself after it calls or
			     Otherwise the presence of the child  that	caused
			     the original signal causes	another	signal immedi-
			     ately, resulting in infinite recursion.

			     Job control shells	including C shell, Korn	 shell
			     and  the POSIX shell (see csh(1), ksh(1), and sh-
			     posix(1)) make the	shell itself the parent	of all
			     processes	in the pipeline.  Therefore, a process
			     that can receive data from	a pipe should not  at-
			     tempt to catch

	      The	     signal is sent to all processes after a power in-
			     terruption	when power is restored and the	system
			     has  done	all  necessary reinitialization.  Pro-
			     cesses restart by catching	(or ignoring)

			     Applications that	wish  to  recover  from	 power
			     failures should catch and take whatever necessary
			     steps to reinitialize itself.

			     Some implementations do not generate Only systems
			     with  nonvolatile	memory	can recover from power
			     failures.

DEPENDENCIES
   Series 700
       The signal is not currently generated.

   Series 700/800
       The structure pointer scp is always defined.

       The code	word is	always zero for	all signals except and	For  code  has
       the following values:

	       8     Illegal instruction trap;

	       9     Break instruction trap;

	      10     Privileged	operation trap;

	      11     Privileged	register trap.

       For code	has the	following values:

	      12     Overflow trap;

	      13     Conditional trap;

	      14     Assist exception trap;

	      22     Assist emulation trap.

       Refer to	the Series 800 processor documentation provided	with your sys-
       tem for more detailed information about the meaning of these errors.

       The Instruction Address Offset Queue (program counter) is not  advanced
       when  a	trap occurs on Series 800 systems.  If a signal	generated by a
       hardware	trap is	masked or has its signal action	 set  to  the  program
       loops infinitely	since the instruction causing the trap is re-executed,
       causing the trap	again.	If the signal is received by a signal-catching
       function	 in  the user program, the instruction that caused the trap is
       re-executed upon	return from the	signal-catching	function  unless  pro-
       gram flow is altered by the signal-catching function.  For example, the
       routine (see setjmp(3C))	can be called.	Using ensures software	porta-
       bility across different hardware	architectures.

AUTHOR
       was developed by	HP, AT&T, and the University of	California, Berkeley.

SEE ALSO
       kill(1),	 init(1M),  bsdproc(3C), exit(2), kill(2), lseek(2), pause(2),
       sigaction(2), signal(2),	sigvector(2), wait(2), sigset(3C),  abort(3C),
       setjmp(3C).

STANDARDS CONFORMANCE
								     signal(5)

NAME | SYNOPSIS | DESCRIPTION | APPLICATION USAGE | SEE ALSO | CHANGE HISTORY | Issue 4 | Issue 4, Version 2 | DESCRIPTION | WARNINGS | DEPENDENCIES | AUTHOR | SEE ALSO | STANDARDS CONFORMANCE

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=signal&sektion=5&manpath=HP-UX+11.22>

home | help