HP-UX HB v13.00 Ch-11 - Software Development

HP-UX Handbook – Rev 13.00 Page 79 (of 101)
Chapter 11 Software Development
October 29, 2013
# echo dump_all/W 0 | adb -w /stand/vmunix /dev/kmem
This flag will not be stored permanently. The setting will be lost after a reboot.
Programs which catch fatal signals that would otherwise cause an abort with core dump, should
provide at least basic information like stacktraces before they exit. If they don’t, the only way to
get a core file for further analysis is to attach to the running process with gdb, stop it when the
signal is delivered to it, and force a core dump before the signal handler is called:
$ gdb –q myprog 13076
(no debugging symbols found)...Attaching to program: myprog, process
13076
warning: The shared libraries were not privately mapped; setting a
breakpoint in a shared library will not work until you rerun the
program; stepping over longjmp calls will not work as expected.
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...
0xc022edd0 in _nanosleep2_sys+0x10 () from /usr/lib/libc.2
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault
si_code: 0 - SEGV_UNKNOWN - Unknown Error.
0xc022edd0 in _nanosleep2_sys+0x10 () from /usr/lib/libc.2
(gdb) dump
Dumping core to the core file core.13076
(gdb) c
Continuing.
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) q
Getting a stacktrace from a core file
Usually debugging always starts with the same action - looking for the location of the abort, by
getting a stacktrace of the thread that aborted:
$ gdb a.out core
HP gdb 5.0 for PA-RISC 1.1 or 2.0 (narrow), HP-UX 11.00
:
(gdb) info threads
* 1 system thread 3785 0x7f7a5378 in printf () from /usr/lib/libc.2