Debugging Core Files Using HP WDB HP Part Number: 5992-0560 Published: February 2008 Edition: 2.
© Copyright 2007–2008 Hewlett-Packard Development Company, L.P. Legal Notices Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license. The information contained herein is subject to change without notice.
Table of Contents About This Document............................................................................................................................9 Intended Audience.................................................................................................................................9 Typographic Conventions......................................................................................................................9 Related Information.......................................
List of Tables 1 2 3 4 System Requirements for Core File Debugging............................................................................14 Commonly Used Commands for Core File Debugging................................................................16 Supported Systems for PA-RISC Core File Debugging.................................................................28 Commands for Debugging a Core File From a Different System.................................................
List of Examples 1 2 3 4 5 6 7 8 9 10 SIGBUS Causes a Core Dump.......................................................................................................12 SIGSEGV Causes a Core Dump....................................................................................................12 SIGABRT Causes a Core Dump....................................................................................................13 Viewing Symbol Information by Using the nm Command..................................
About This Document This document describes how to debug core files and analyze the process state of an application, using HP WDB. Intended Audience This document is intended for C, Fortran, and C++ programmers who use HP WDB to debug core files generated by HP C, HP aC++, and Fortran90 compilers. Readers of this document must be familiar with the basic commands that HP WDB supports.
Related Information The following table lists the documentation available for HP WDB. Document Location Debugging with GDB /opt/langtools/wdb/doc/gdb.pdf GDB Quick Reference Card /opt/langtools/wdb/doc/refcard.pdf Getting Started With HP WDB /opt/langtools/wdb/doc/html/wdb/C/GDBtutorial.html WDB GUI Online Help /opt/langtools/wdb/doc/index.
Introduction HP Wildebeest Debugger (WDB) is an HP-supported implementation of the open source debugger GDB. Apart from performing the normal debugging functions, it also enables you to debug core files and analyze the process state of an application.
Example 1 SIGBUS Causes a Core Dump $ cat a.c #include int main() { char a[64], *b; int *i; b = a; b++; i = (int *)b; printf("%i", *i); return 0; } $ aCC a.c -o a $ ./a Memory fault(core dump) $file core core: core file from 'a' - received SIGBUS In this example, the program attempts to load a data item at a non-aligned address, which results in a SIGBUS signal. The variable a is a local variable on the stack. The pointer b is set to point to the start of a.
• SIGABRT A SIGABRT signal can be sent to a process in any of the following ways: — — — The process can send the abort signal, SIGABRT, by invoking the abort(3) function. Another process or the user can invoke the kill command to send the SIGABRT signal. As a result of calls to C++ terminate() function on various runtime library errors. Example 3 (page 13) illustrates a SIGABRT signal caused by a call to terminate(). Example 3 SIGABRT Causes a Core Dump $ cat gdb_throw_example.c #include
Support for Invoking GDB Before a Program Aborts WDB also provides the -crashdebug option to monitor the program execution and invoke the debugger when the program execution is about to abort. This option provides support for debugging a live process before the program aborts, instead of debugging the core file after the program aborts. Once the debugger is invoked, you can debug the application by using the common debugger commands.
Commands For Core File Debugging This section discusses the commands for debugging core files. Invoking WDB to Debug Core Files To invoke the debugger on the core file, enter one of the following commands: • At the HP-UX prompt: $ gdb a.out core or $ 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.
If the shared libraries are located at a path that is different from the invoked path, you must provide WDB with the path for the shared libraries.
Table 2 Commonly Used Commands for Core File Debugging (continued) Debugging Feature Command Viewing thread info thread information thread thread apply [all]args backtrace-other-thread Description The info thread command enables you to view the list of all the threads in the process at the time of core dump. The thread command enables you to switch the thread view under the debugger from one thread to another.
Table 2 Commonly Used Commands for Core File Debugging (continued) Debugging Feature Examining memory Command Description x /[x|s|d]
Displays memory information of a specified address. The x / x command prints the contents of the specified memory address in hexadecimal format. The x / s command prints the contents of the address of a string. The x / d command prints the contents of the address in decimal format.Example 6 (page 32) and Example 7 (page 39) illustrate the use of the common core file debugging commands.
What is a Symbol Table? A symbol table is a set of records that define the set of visible and important symbols in a program. These symbols are stored in the program. Each (unstripped) program has an associated symbol table. The nm command displays the symbol information for a specified object file. Example 4 illustrates how to view symbol information for an object file by using the nm command for an object file, on an HP 9000 system.
Example 8 (page 40) illustrates the core file debugging for a stripped binary when the symbol table of the unstripped program is available. Example 9 (page 41) illustrates the core file debugging for a stripped binary when the symbol table is available from another program, which uses the same symbols, but in a different link order.
• • The static function names appearing in the stack traces are not displayed. The debugger may print random names instead of while displaying these function names. In the case of core files created by PA-RISC binaries, the function names (static and non-static) appearing in the stack are not displayed. NOTE: • To avoid these limitations in debugging core files created by stripped binaries, you can use the original unstripped version of the executable, if it is available.
Example 5 Debugging Core Files Created by Optimized Code, Stripped Binaries, and Code Compiled Without the -g Option Sample Program 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 // a.c // Generates coredump with 3 deep stack trace. #include
#1 0x4000a00:0 in inline foo () at a.c:30 #2 0x40009b0:1 in main () at a.c:37 (gdb) up #1 0x4000a00:0 in inline foo () at a.c:30 30 generate_core_dump(); (gdb) p local_j No symbol "local_j" in current context. The debugger cannot display information about the arguments and local variables because the program is compiled with the -O option (level 2 optimization). However, the debugger can display the inlined functions in the backtrace and provide the line number information.
$ aCC -g a.c $ strip a.out $ /opt/langtools/bin/gdb ./a.out core HP gdb for HP Itanium (32 or 64 bit) and target HP-UX 11.2x. Copyright 1986 - 2001 Free Software Foundation, Inc. Hewlett-Packard Wildebeest (based on GDB) is covered by the GNU General Public License. Type "show copying" to see the conditions to change it and/or distribute copies. Type "show warranty" for warranty/support. .. warning: Load module ./a.out has been stripped. Debugging information is not available. (no debugging symbols found)..
Forcing a Core Dump WDB enables you to force a core dump of a running process, and analyze the core file. The dumpcore command forces a core dump and generates a core image file for a process that is running under the debugger. If no arguments are given, it saves the core image for the current debugged process in a file named core., where is the process ID number. Before debugging a forced core dump, you must enter the set live-core 1 command at the gdb prompt.
Type "showwarranty" for warranty/support.... Core was generated by ’sample’. #0 main() at sample.
Debugging Core Files From a Different System When debugging a core file, the debugger requires the exact versions of shared libraries and the executable that are associated with the core file.
created by unpackcore. The getcore command accepts the name of the packcore directory as an argument. Debugging PA-RISC Core Files on Integrity Systems Using WDB, you can transparently debug PA-RISC programs running in compatibility mode under Aries on Integrity systems. To debug a core file generated by a PA-RISC program on an Integrity system, complete the following steps: 1. 2. 3.
Avoiding Core File Corruption You can prevent overwriting of core files from a different process by setting the kernel to store the core file in a process-specific file name, (where pid is the process ID of the process that dumped the core).
core_addpid: 1 = 0 core_addpid: 1 = 0 Avoiding Core File Corruption for Applications Running HP-UX 11i v3 To prevent overwriting of core files from different processes for applications running in HP-UX 11i v3, you can use the coreadm commandl. The coreadm command enables you to specify the location and pattern for core files that are created by abnormally terminating processes. This command can also be used to specify the path for the core file placement.
Examples Illustrating Core File Debugging The examples in this section are for core files that are created on an HP 9000 system (PA-RISC). If the program is not compiled with -g, the line number information is not available in the case of core files on PA-RISC systems. On the contrary, the source line number information is available for core files created by Itanium-based binaries, irrespective of whether the core file is compiled with the -g option, or not.
2. View the backtrace information to analyze the flow of routines in the program that resulted in a program abort. The following backtrace information of the core file illustrates that function_abort() invoked the abort library call in libc to kill the process: (gdb) bt #0 0xc01082b8 in kill () from /usr/lib/libc.2 #1 0xc00a52e8 in raise () from /usr/lib/libc.2 #2 0xc00e5c8c in abort_C () from /usr/lib/libc.2 #3 0xc00e5ce4 in abort () from /usr/lib/libc.
0x2410 0x2414 0x2418 0x241c 0x2420 0x2424 0x2428 End of : : : : : : : assembler dump. stw %r22,4(%sr0,%r21) ldil L'0x2000,%r31 be,l 0x3dc(%sr4,%r31) copy %r31,%rp ldw -0x54(%sr0,%sp),%rp bv %r0(%rp) ldo -0x40(%sp),%sp If the parameters are not stored on the stack, the task of reading the core file is similar to reading a kernel crash dump.
7. To determine the value of the variables, you must analyze the contents of the required memory location. In this example, the value of arg1 is an integer, and hence this value is 32(0x20). The argument, arg0, is a pointer to a structure. To arrive at the value of arg0, the offsets for the variables in the structure must be determined manually.
(gdb) x/x 0x7f7e6688+0x8 0x7f7e6690: 0x7f7e669c Similarly, the offsets for the following structure st_two are calculated: struct st_two { char *a; int b; float c; char *d; }; 36 +0x0 +0x4 +0x8 +0xC
The values of the variables in the structure st_two are determined by using these offsets, as follows: — To examine the first word of the structure st_two, enter the following command at the gdb prompt: (gdb) x/x 0x7f7e669c 0x7f7e669c: 0x40001130 To display the string value at this address, enter the following command at the gdb prompt: gdb) x/s 0x40001130 0x40001130 <__d_trap_fptr+276>: "of life" — To examine the second word of the structure st_two, enter the following command at the gdb prompt: (gdb)
• Method 2: In this method, you can use the gdb convenience variables to store and manipulate memory addresses. You can use the show conv command to view the current values of the convenience variables. The nomenclature of all convenience variables is such that they start with the $ symbol.
Example 7 Debugging a Core File to View Information on a Global Variable in a C program In this example, the address, &global_vars, of global_vars is required for debugging. If the required structure is a pointer, the address of the structure is not required. The address of the structure is cast to (char*) so that any increments to this address will be 1 byte. The program in this example uses the global structure, global_vars.
Example 8 Debugging a Core File Created by a Stripped Binary When the Symbol Table is Available Sample Program The program in this example has the following global structure, global_vars: struct gvals { char *program; +0x0 int arg_count; +0x4 char *first_arg; +0x8 char *path; +0xC int secret; +0x10 }; struct gvals global_vars; Sample Debugging Session This sample debugging session illustrates how to debug a core file that is created by the stripped binary of this program.
Example 9 Debugging of a Core File Created by a Stripped Binary When the Symbol Table is Available from Another Program In this example, three copies of a program (program a1, program a2, and program a3 ) are compiled and linked with a different order. For example: Program a1 is stripped. Program a2 is an unstripped copy of program a1. Program a3 is functionally the same as program a1. However, the code and the symbols are in a different link order.
#4 0x2498 in a () from /home/shane/test/./a1 #5 0xc018fc94 in raise () from /usr/lib/libc.2 If the program is built with debug support, you can use the symbol information from this program to debug the stripped version of the program.
Example 10 Core File Debugging Session for a Stripped Binary When the Symbol Table is Available from Another Program This example is similar to Example 9 (page 41). This example illustrates the debugging of a stripped binary when the symbol table is available from another program that uses the same symbols. The programs, example.c and example2.c , have the same symbol table. Sample Program 1 $ cat example.c #include #include
int function_abort(struct st_one *a, int b) { a->three->b=99; abort(); } Sample Program 2 $ cat example2.c struct st_two { char *a; int b; float c; char *d; }; struct st_one { int one; char *two; struct st_two *three; int *four; char *five; }; main() { } Sample Debugging Session In this example,example.c is compiled and stripped. The program,example2.c, is compiled with the -g option.
$ aCC -g example2.c -o example2 $ aCC -g example.c -o example $ strip example $ ./example Abort(coredump) $ gdb example core HP gdb ... Core was generated by `example'. Program terminated with signal 6, Aborted. warning: The shared libraries were not privately mapped; setting a breakpoint in a shared library will not work until you rerun the program. (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...#0 0xc01082b8 in kill () from /usr/lib/libc.
From previous disassembling we know that the pointer to the struct st_one was stored at -0x64 (-100) on from $sp in the function_abort routine. However, the pointer to the structure is stored on the stack. Taking the offset from the stack pointer into account, we must deference the pointer twice to get from the stack pointer to the structure, and subsequently dereference this structure to print all the members of this structure.
FAQ 1 Are shared memory segments dumped in the core file by default? No. However, the shared memory segments can be dumped into the core file if you set the following kernel symbols: • core_addshmem_read This kernel symbol controls if shared memory segments that are mapped read-only into a process are dumped in a core file.
. . .
