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:

  1. You compile the program with separate debug information, and ship the object code without the debug information.
  2. You ship the @ITRAPPER; utility along with your application.
  3. 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;.
  4. 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;