HP 3000 Manuals HP 3000 Manuals
Debugging MPE XL Arithmetic Traps
Arithmetic traps result from various types of arithmetic errors. The
types of MPE XL arithmetic traps are listed in Chapter 2. These traps
can be caught and handled.
You have three basic options when debugging MPE XL arithmetic traps:
* Use a stack trace and the system debugger
* Examining the problem by arming a trap handler using the XARITRAP
intrinsic
* Handling the problem by arming a trap handler using the XARITRAP
intrinsic
Using Stack Trace and the System Debugger
You can use a stack trace and the system debugger to find the cause of
the trap. Refer to Examples 1-1 and 1-2 for illustrations of the types
of stack traces. For more information about stack traces, the SETDUMP
intrinsic, and use of the system debugger, refer to the System Debug
Reference Manual (32650-90013).
Using a Trap Handler to Examine the Problem
The basic record of information supplied to the user-defined arithmetic
trap handler for all arithmetic traps contains the following four
information fields:
* Offending instruction
* Offset of the offending instruction
* Space ID of the offending instruction
* Error code, specifying which type of arithmetic trap occurred
Certain specific information is also provided, depending on the type of
trap. In several instances, subcodes narrow the problem down further.
For example, for an integer overflow, the subcodes identify the overflow
as being 16-bit, 32-bit, in conversion from HP3000_16 format, or in
conversion from IEEE format. Pointers are provided to the target,
allowing you to modify the result to any desired value. For IEEE
floating point traps, the floating point operation that caused the trap
is given, along with pointers to the source and result values. For more
information, refer to the discussions in Chapter 2.
You can deduce much about the source of the problem by formatting and
displaying the information provided by these records. Consider these
strategies:
* The type of trap is valuable in setting the scene for all further
actions in solving or correcting the problem. For instance, knowing
you have an integer zero divide error allows you to concentrate only
on integer variables as you try to determine how the zero arrives in
the denominator.
* Given the space and offset of the error, you can run the program
again with the system debugger. You can obtain the name of the
offending procedure and the offset within that procedure by turning
on the windows and paging to that location. Depending on programming
practice and available options, you may be able to obtain the line
number of the offending statement by looking above this location.
Otherwise, further effort may be needed to determine the offending
source statement.
* The actual instruction can tell you what operation is being
attempted.
* Subcodes specifying size may help limit the error possibilities. For
instance, knowing you only have to be concerned about 16-bit integers
may sometimes reduce the number of variables you have to investigate.
* Looking at the sources of an operation (IEEE, decimal, or ASCII
formats) can sometimes quickly point to the offending variable since
you might know what the value should look like.
Using a Trap Handler to Handle the Problem
An alternative to examining the problem is to arm a user-defined
arithmetic trap handler using the XARITRAP intrinsic and either correct
or ignore the problem. This approach allows program execution to
continue.
Consider the following strategies:
* In a particular program, you might decide that for some reason, all
zero divide errors should have the result set to 100. Instead of
checking the dividend prior to each divide, you could set a trap
handler to do this for you. Therefore, when the system issues a
trap, you can modify the result and continue just as the program
expects.
* Invalid digits (ASCII or decimal formats) can be corrected by the
user-defined arithmetic trap handler. The trap handler could also
prompt you to input proper values. In this way, the operation can be
performed again without aborting the process.
* Regarding overflow conditions, you might decide that the error does
not really matter. In such an instance, the trap handler can allow
execution to continue without anything being done.