Middleware, development tools, realtime operating system
software and services for superior embedded design


Home
QNX Community Resources
Developer Support
QNX Documentation Library
QNX Developer Support

QNX Developer Support

QNX Software Systems
Developer Resources
Blogs
Board support packages
Foundry27 projects
Forums
Hardware support listing
Online video tutorials
Product documentation
Technical Articles

[Previous] [Contents] [Index] [Next]

dumper

Dump the postmortem state of a program (QNX)

Syntax:

dumper [-d path] [-m] [-n] [-p pid] [-s size[G|M|K]]
       [-v] [-w] &

Options:

-d path
The name of the directory in which to write postmortem dump files. The default is your home directory.
-m
Don't dump memory.
-n
Save sequential dumps. Each dump is saved in a file whose name is in the form:

executable.num.core

where num starts at 1 and increases until the filename doesn't already exist.

-p pid
Save a dump file for this process immediately, and then exit dumper.
-s size[G|M|K]
Set the maximum core size, in bytes.
-v
Be verbose.
-w
Make core files world-readable.

Description:

The dumper utility runs in the background and provides a postmortem dump service for all processes. Whenever a program terminates abnormally, a dump of the current state of the program is written to disk. The dump filename is the same as the program name with a .core extension. For example, if the program name is experiment, the dump is written to experiment.core in your home directory.


Note: On a QNX Momentics system, dumper starts with dumper -d /var/dumps.

You can use the -d option to force all dumps into a directory other than /var/dumps.


Note: Dump files can be large, so make sure the destination filesystem has lots of space.

The -p option lets you get a dump immediately for a particular process. If you specify -p, dumper doesn't run in the background, but exits right away.

You can use a debugger such as gdb to examine a dump file:

gdb program_binary program_core 

For example:

gdb /usr/photon/bin/pterm /var/dumps/pterm.core

A program may terminate in one of two ways: it may exit cleanly under its own control, returning an exit status, or it may be forcibly terminated by the receipt of a signal that it isn't prepared to handle. In the latter case, dumper writes a dump file for the following set of signals:

Signal Description
SIGABRT Program-called abort function
SIGBUS Parity error
SIGEMT EMT instruction
SIGFPE Floating-point error or division by zero
SIGILL Illegal instruction executed
SIGQUIT Quit
SIGSEGV Segmentation violation
SIGSYS Bad argument to a system call
SIGTRAP Trace trap (not reset when caught)
SIGXCPU Exceeded the CPU limit
SIGXFSZ Exceeded the file size limit

You can force the dump of a running program by setting one of the preceding signals, assuming that the program isn't masking or handling the signal itself. For example, to force a dump using the kill command and a process ID (pid):

kill -SIGABRT pid

To force a dump using the slay utility and the process name:

slay -s SIGABRT process_name

Examples:

Start dumper, with dump files to be written to the default directory:

dumper &

Start dumper, with dump files to be placed in the directory /home/dumps:

dumper -d /home/dumps &

Exit status:

The dumper utility normally doesn't terminate. However, it may terminate if it encounters an error on startup (for instance, if it wasn't run by root) or if it receives a signal.

0
A signal was received and dumper shut down successfully.
1
An error was encountered on startup (not run by root or bad command-line options).

See also:

coreinfo, gdb, kill, slay


[Previous] [Contents] [Index] [Next]