Stages of postmortem debugging: OS/2 local debugging only
Note: This section applies only to OS/2 local debugging.
Postmortem debugging is intended to help you isolate the causes of unanticipated traps
or OS/2 exceptions, in programs that are already in production or widespread use. The
stages of the postmortem debugging process are:
- You compile the program with separate debug information, and
ship the object code without the debug information.
- You ship the @ITRAPPER; utility along with your application.
- After the end user has experienced a trap or unanticipated OS/2 exception, or in
anticipation of such a problem, they reload the application under @ITRAPPER;. This utility
has no effect on the running application. However, if the application traps or throws an
unhandled exception, @ITRAPPER; takes control and writes relevant information to a dump
file, using compression algorithms to minimize the dump file size. If the failure causing
the trap was an OS/2 exception, the program continues running. If the cause was a trap,
the program terminates. A separate dump file is created for each exception or trap. The
end user ships you the dump files created by @ITRAPPER;.
- You debug the dump file instead of a live class file. Because the dump file contains
information about the state of the application at the time of the trap or exception, and
is not a live class file, only a subset of debugger features are available. For example,
you can view memory and register contents, but you cannot step or run the program or set
breakpoints.

Separate debug information

@ITRAPPER;