Guardian Procedure Errors and Messages Manual

21 Traps and Signals
Certain critical problems can cause a process to be unable to continue executing. These are typically
the result of coding errors, but other conditions, such as the lack of a system resource (for example,
memory), can also prevent normal process execution. Such conditions are reported as traps to
TNS processes and as signals to TNS/R native processes.A trap is a software mechanism that
stops process execution.A signal is a software interrupt that can notify a process of other events,
such as timer expiration, as well as of critical error conditions.
The set of signals that are used in the Guardian environment is known as TNS/R native signals.
This set is a subset of a larger set of signals used in the Open System Services (OSS) environment.
Most of the TNS/R native signals are caused by the same conditions that cause traps to occur in
TNS processes. TNS processes in the Guardian environment do not receive signals, except under
rare circumstances that cause a trap 8 to be generated.
In this section, equivalent trap and signal conditions are described together.Signals are commonly
referred to by name, where each name is a literal that stands for a 32-bit signal number.
Table 30 lists the TNS/R native signals by name, in alphabetic order, along with their signal
numbers, the equivalent trap numbers, and brief trap descriptions.
Table 30 TNS/R Native Signal Names, Signal Numbers, Trap Numbers, and Trap Descriptions
Trap DescriptionTrap NumberSignal NumberSignal Name
(not available to TNS processes)none6DSIGABRT
(not available to TNS processes)none14DSIGALRM
Arithmetic overflow28DSIGFPE
Instruction failure14DSIGILL
Limits exceeded527DSIGLIMIT
Uncorrectable memory error1322DSIGMEMERR
Memory manager read error1124DSIGMEMMGR
No memory available1223DSIGNOMEM
Illegal address reference011DSIGSEGV
Stack overflow325DSIGSTK
Process loop-timer timeout426DSIGTIMEOUT
(signal delivered to TNS process)8--other signals
Trap Handling
When a trap occurs, control passes to the Debug or Inspect debugger by default. However, by
using the ARMTRAP system procedure, a program can specify a trap handler to be executed when
the trap occurs or, alternatively, that a trap causes the program to abend. The actions of a trap
handler typically include either terminating the process or, in certain cases, resuming execution.
For information about the Debug and Inspect debuggers, see the Debug Manual and the Inspect
Manual.
For a description of the ARMTRAP procedure, see the Guardian Procedure Calls Reference Manual.
For an explanation of how to create your own trap handler with ARMTRAP, see the Guardian
Programmer's Guide.
Trap Handling 273