Click above to get retro games delivered to your door ever month!

A limited form of debugging of an application that has terminated and
produced a postmortem dump can be done under QNX.  In order to use this
feature, you must start the QNX "dumper" program.


     dumper [-d path] [-p pid] &

dumper
    is the program name for the QNX postmortem dump program.

-d path
    The name of the directory in which postmortem dumps are written.  If not
    specified, the default is the user's home directory.

-p pid
    Save a dump file for this process if it terminates for any reason.  Do
    not save a dump file for any other process.

&
    must be specified so that the shell is rejoined.

Example:

     $ dumper &
     $ dumper -d /usr/fred/dump_area &

Whenever a program terminates abnormally, a dump of the current state of the
program in memory is written to disk.  The dump file name is the same as the
program name with a .dmp extension.  For example, if the program name is
a.out then the dump will be written to the /home/userid/a.out.dmp file.

You can use the -d option of the dumper program to force all dumps into a
single directory rather than into the invoking user's home directory.

The -p option lets you monitor a particular process.  You can run multiple
copies of the dumper program, each monitoring a different process.

If the Watcom Debugger was being used to debug the program at the time that
it abnormally terminated then the dump is written to the user's home
directory provided that the -d option was not used.

To examine the contents of the postmortem dump, the Watcom Debugger may be
used.  The interface between the Watcom Debugger and the postmortem dump is
contained in a special "trap" file.  The trap file is specified to the
Watcom Debugger using the "TRAP" option.


     wd -TRap=pmd[;i] [:sym_file] file_spec

wd
    is the program name for the Watcom Debugger.

-TRap=pmd[
    i] must be specified when debugging an application that has terminated
    and produced a postmortem dump.  The optional ";i" is specified when the
    modification date of the original program file does not match the
    information contained in the dumper file.  It indicates that the
    symbolic debugging information in the program file may be out-of-date.
     It instructs the Watcom Debugger to ignore the date mismatch.
     Depending on the shell that you are using, it may be necessary to place
    the option specification in quotation marks if you include the optional
    ";i".

    Example:

         $ wd "-trap=pmd;i" myapp

sym_file
    is an optional symbolic information file specification.  The
    specification must be preceded by a colon (":").  When specifying a
    symbol file name, a path such as "//5/etc/" may be included.  For QNX,
    the default file suffix of the symbol file is ".sym".

file_spec
    is the file name of the dumper file to be loaded into memory.  When
    specifying a file name, a path such as "//5/etc/" may be included.  If a
    path is omitted, the Watcom Debugger will first attempt to locate the
    file in the current directory and, if not successful, attempt to locate
    the file in the default dumper directory:  /usr/dumps.

Basically, the Watcom Debugger is fully functional when a postmortem dump is
examined.  However, there are some operations which are not allowed.  Among
these are:

 1. Task execution cannot be restarted using Go from the Run menu.

 2. A register can be modified for the purposes of expression evaluation.
     You can choose Go from the Run menu to restore the register contents to
    their original postmortem state.

 3. Memory cannot be modified.

 4. Memory outside of regions owned by the program cannot always be
    examined.

 5. I/O ports cannot be examined.