Debugging Core Files Using HP WDB (5900-1573; WDB 6.2; January 2011)

$ gdb a.out -c core
or
$ gdb -c core
• (Or) At the gdb prompt:
(gdb) core core
(where a.out is the executable that dumped core.)
If the executable path is not provided, the debugger selects the invocation path of the
process that generated the core file. The invocation path information is stored in the core
file. If the invocation path is a relative path, you must specify the executable to debug
the core file.
On invoking the core file debugging session, the debugger displays the following
information (depending on the debug information available):
• The signal that caused the core file
• The cause of the un-handled signal
• The instruction at which this signal occurred
• The function name and the parameters of the function in which this instruction resides
• The source line information
The following example illustrates the output from the debugger on invoking a core file
debugging session:
..
Core was generated by `a.out'.
Program terminated with signal 11, Segmentation fault.
SEGV_ACCERR - Invalid Permissions for object
#0 inline generate_core_dump () at a.c:11
11 printf ("Generated coredump\n");
(gdb) bt
#0 inline generate_core_dump () at a.c:11
#1 0x4000a00:0 in inline foo () at a.c:30
#2 0x40009b0:1 in main () at a.c:37
Setting the Path for the Relevant Shared Libraries
The core files do not carry information about the exact version of shared libraries that
were in use at the time of core dump. Analyzing a core file without the correct versions
of shared libraries can produce misleading results. Hence, you must provide information
about the relevant shared libraries before initiating a core file debugging session. All
the required libraries must be copied to a temporary location on the system where you
are debugging the core file (if it is different from the system where the core file was
generated).
Commands For Core File Debugging 11