| Previous | Contents | Index |
When the operating system encounters an irrecoverable error running a program, the system creates a file named core and places it in the current directory. The core file is not an executable file; it is a snapshot of the state of your program at the time the error occurred. It allows you to analyze the program at the point it crashed. This chapter describes a technique you can use to debug core files using the debugger.
Kernel debugging can be very helpful in analyzing kernel crash dumps.
For information on kernel debugging, see Chapter 17.
11.1 Invoking the Debugger on a Core File
You can use the debugger to examine the program information in a core
file.
Use the following ladebug command syntax
to invoke the debugger on a core file:
ladebug executable_file core_file
Specify the name of the executable file (the program that was running
at the time the core file was generated) in addition to the core file.
11.2 Core File Debugging Technique
When debugging a core file, use the debugger to obtain a stack trace and the values of a few variables.
The stack trace lists the functions in your program that were active when the dump occurred. By examining the values of a few program variables along with the stack trace, you should be able to pinpoint the program state and the cause of the core dump. (Core files cannot be executed, and so a rerun, step, cont, etc. will not work until a run is issued.)
In addition, if the program is multithreaded, you can examine the native (that is, kernel-level) thread information with the show thread and thread commands. You can examine the stack trace for a particular thread or all threadswith the where thread command. (See Section 11.3. Also see Chapter 10.)
This program uses a null pointer reference in the factorial function. This reference causes the program to abort and dump the core when it is executed. The dump command prints the value of the x variable as a null, and the print *x command reveals that you cannot dereference a null pointer.
| Example 11-1 Debugging a Core File |
|---|
% cat testProgram.c
main() {
int i,f;
for (i=1 ; i<3 ; i++) {
f = factorial(i);
printf("%d! = %d\en",i,f);
}
}
factorial(i)
int i;
{
int *x;
x = 0;
printf("%d",*x);
if (i<=1)
return (1);
else
return (i * factorial(i-1) );
}
% cc -o testProgram -g testProgram.c
% testProgram
Memory fault - core dumped.
% ladebug testProgram core
Welcome to the Ladebug Debugger Version 4.0
------------------
object file name: testProgram
core file name: core
Reading symbolic information ...done
Core file produced from executable testProgram
Thread terminated at PC 0x120000dc4 by signal SEGV
(ladebug) where
>0 0x120000dc4 in factorial(i=1) testProgram.c:13
#1 0x120000d44 in main() testProgram.c:4
(ladebug) dump
>0 0x120000dc4 in factorial(i=1) testProgram.c:13
printf("%d",*x);
(ladebug) print *x
Cannot dereference 0x0
Error: no value for *x
(ladebug)
|
Ladebug can debug core files generated by multithreaded applications. For this kind of core file debugging, Ladebug sets the $threadlevel variable to native in the following initializations:
Ladebug will not set the $threadlevel variable correctly in the following case: Process A, not a core file, is attached with the $threadlevel set to native. Switching to Process B and then back to Process A resets the variable to decthreads rather than native. |
Example 11-2 presents an example of core file kernel thread debugging.
| Example 11-2 Debugging a Multithreaded Kernel Core File |
|---|
Welcome to the Ladebug Debugger Version 4.0-10 ------------------ object file name: ../bin/c_threadcore Reading symbolic information ...done (ladebug) record io out (ladebug) unload (ladebug) load ../bin/c_threadcore ../bin/c_threadcore_core Reading symbolic information ...done Core file produced from executable c_threadcore Thread 0xffffffff836934d0 terminated at PC 0x3ff805065c8 by signal SEGV (1) (ladebug) print $threadlevel(2) "native" (ladebug) show thread(3) Thread # Id State > 1 0xffffffff836934d0 dead 2 0xffffffff83596120 dead (ladebug) thread(4) Thread 0x1 (ladebug) where(5) >0 0x3ff805065c8 in __kill(0xb, 0x2, 0x3, 0x47c18, 0x4, 0x6) ../../../../../src/usr/ccs/lib/libc/alpha/kill.s:41 #1 0x3ff8055c560 in exc_raise(0x3ffc01e7e78, 0x0, 0x1, 0x0, 0x309a9a07, 0xb97c60) ../../../../../src/usr/ccs/lib/DECthreads/COMMON/ exc_handling.c:649 #2 0x3ff8055c764 in exc_pop_ctx(0x3ffc01e7bd0, 0x0, 0x0, 0x3ff80567b40, 0x0, 0x0) ../../../../../src/usr/ccs/lib/DECthreads/COMMON/ exc_handling.c:805 #3 0x3ff8056e374 in cma__thread_base(0x0, 0x0, 0x0, 0x0, 0x0, 0x1200136e0) ../../../../../src/usr/ccs/lib/DECthreads/COMMON/ cma_thread.c:1623 (ladebug) thread 2(6) Thread 0x2 (ladebug) where(7) >0 0x3ff8051df04 in msg_receive_trap(0xe56b0, 0x0, 0x3ff804b500c, 0x100000000000, 0x3ff804b5058, 0x18157f0d0d) /usr/sde/osf1/build/ goldminos.bld/export/alpha/usr/include/mach/syscall_sw.h:74 #1 0x3ff80514764 in msg_receive(0xe0df0, 0x0, 0x0, 0x240000000000000, 0x61746164702e, 0x3ff800b9fe0) ../../../../../src/usr/ccs/lib/libmach /msg.c:95 #2 0x3ff80574b00 in cma__vp_sleep(0x2801000000, 0x3ff00000001, 0x6, 0x3ffc00841a0, 0x3ff00000000, 0x3ffc00960c0) ../../../../../src/usr/ ccs/lib/DECthreads/COMMON/cma_vp.c:1588 #3 0x3ff8055ae7c in cma__dispatch(0x6, 0x3ffc00841a0, 0x3ff00000000, 0x3ffc00960c0, 0x3ff80554354, 0x3ffc0080468) ../../../../../src/usr/ccs/ lib/DECthreads/COMMON/cma_dispatch.c:998 #4 0x3ff80554354 in cma__int_wait(0x11ffff428, 0x4ac18, 0x3ffc01de9f8, 0x70000003, 0x3ff80485192, 0x3ff80089931) ../../../../../src/usr/ccs/ lib/DECthreads/COMMON/cma_condition.c:2651 #5 0x3ff8056d704 in cma_thread_join(0x11ffff848, 0x11ffffbf0, 0x11ffffbe8, 0x3ff8056e110, 0x0, 0x3ffc01e3de0) ../../../../../src/ usr/ccs/lib/DECthreads/COMMON/cma_thread.c:955 #6 0x3ff80563a2c in pthread_join(0x47c18, 0x400000000000002, 0x11ffffc68, 0x3ffc01de9f8, 0x120013d18, 0x5) ../../../../../src/usr/ ccs/lib/DECthreads/COMMON/cma_pthread.c:2270 #7 0x120013d70 in main() thread_core.c:92 (ladebug) where thread all(8) Stack trace for thread 1 #0 0x3ff805065c8 in __kill(0xb, 0x2, 0x3, 0x47c18, 0x4, 0x6) ../../../../ ../src/usr/ccs/lib/libc/alpha/kill.s:41 #1 0x3ff8055c560 in exc_raise(0x3ffc01e7e78, 0x0, 0x1, 0x0, 0x309a9a07, 0xb97c60) ../../../../../src/usr/ccs/lib/DECthreads/COMMON/exc_handling.c:649 #2 0x3ff8055c764 in exc_pop_ctx(0x3ffc01e7bd0, 0x0, 0x0, 0x3ff80567b40, 0x0, 0x0) ../../../../../src/usr/ccs/lib/DECthreads/COMMON/ exc_handling.c:805 #3 0x3ff8056e374 in cma__thread_base(0x0, 0x0, 0x0, 0x0, 0x0, 0x1200136e0) ../../../../../src/usr/ccs/lib/DECthreads/ COMMON/cma_thread.c:1623 Stack trace for thread 2 >0 0x3ff8051df04 in msg_receive_trap(0xe56b0, 0x0, 0x3ff804b500c, 0x100000000000, 0x3ff804b5058, 0x18157f0d0d) /usr/sde/osf1/build/ goldminos.bld/export/alpha/usr/include/mach/syscall_sw.h:74 #1 0x3ff80514764 in msg_receive(0xe0df0, 0x0, 0x0, 0x240000000000000, 0x61746164702e, 0x3ff800b9fe0) ../../../../../src/usr/ccs/lib/libmach/ msg.c:95 #2 0x3ff80574b00 in cma__vp_sleep(0x2801000000, 0x3ff00000001, 0x6, 0x3ffc00841a0, 0x3ff00000000, 0x3ffc00960c0) ../../../../../src/usr/ ccs/lib/DECthreads/COMMON/cma_vp.c:1588 #3 0x3ff8055ae7c in cma__dispatch(0x6, 0x3ffc00841a0, 0x3ff00000000, 0x3ffc00960c0, 0x3ff80554354, 0x3ffc0080468) ../../../../../src/usr/ ccs/lib/DECthreads/COMMON/cma_dispatch.c:998 #4 0x3ff80554354 in cma__int_wait(0x11ffff428, 0x4ac18, 0x3ffc01de9f8, 0x70000003, 0x3ff80485192, 0x3ff80089931) ../../../../../src/usr/ccs/ lib/DECthreads/COMMON/cma_condition.c:2651 #5 0x3ff8056d704 in cma_thread_join(0x11ffff848, 0x11ffffbf0, 0x11ffffbe8, 0x3ff8056e110, 0x0, 0x3ffc01e3de0) ../../../../../src/usr/ccs/lib #6 0x3ff80563a2c in pthread_join(0x47c18, 0x400000000000002, 0x11ffffc68, 0x3ffc01de9f8, 0x120013d18, 0x5) ../../../../../src/usr/ #7 0x120013d70 in main() thread_core.c:92 (ladebug) thread 1(9) Thread 0x1 (ladebug) printregs(10) $r0 [$v0] = 0 $r1 [$t0] = 0 $r2 [$t1] = 4396974517024 $r3 [$t2] = 320024 $r4 [$t3] = 4396974517024 $r5 [$t4] = 0 $r6 [$t5] = 0 $r7 [$t6] = 130 $r8 [$t7] = 0 $r9 [$s0] = 2 $r10 [$s1] = 2 $r11 [$s2] = 0 $r12 [$s3] = 0 $r13 [$s4] = 0 $r14 [$s5] = 0 $r15 [$s6] = 0 $r16 [$a0] = 28613 $r17 [$a1] = 11 $r18 [$a2] = 4396974766704 $r19 [$a3] = 0 $r20 [$a4] = 0 $r21 [$a5] = 4 $r22 [$t8] = 3 $r23 [$t9] = 0 $r24 [$t10] = 3 $r25 [$t11] = 0 $r26 [$ra] = 4395904648544 $r27 [$t12] = 4395904749552 $r28 [$at] = -1 $r29 [$gp] = 4396974751200 $r30 [$sp] = 4396974766800 $r31 [$zero]= 0 $f0 = 0 $f1 = 0 $f2 = 0 $f3 = 0 $f4 = 0 $f5 = 0 $f6 = 0 $f7 = 0 $f8 = 0 $f9 = 0 $f10 = 0 $f11 = 0 $f12 = 0 $f13 = 0 $f14 = 0 $f15 = 0 $f16 = 0 $f17 = 0 $f18 = 0 $f19 = 0 $f20 = 0 $f21 = 0 $f22 = 0 $f23 = 0 $f24 = 0 $f25 = 0 $f26 = 0 $f27 = 0 $f28 = 0 $f29 = 0 $f30 = 0 $f31 = 0 $pc = 0x3ff805065c8 (ladebug) thread 2 Thread 0x2 (ladebug) printregs $r0 [$v0] = -207 $r1 [$t0] = 0 $r2 [$t1] = 0 $r3 [$t2] = 0 $r4 [$t3] = 0 $r5 [$t4] = 0 $r6 [$t5] = 1 $r7 [$t6] = 1 $r8 [$t7] = 0 $r9 [$s0] = 4831834496 $r10 [$s1] = 0 $r11 [$s2] = 4396974730048 $r12 [$s3] = 0 $r13 [$s4] = 0 $r14 [$s5] = 162129586585337856 $r15 [$s6] = 0 $r16 [$a0] = 4831834496 $r17 [$a1] = 0 $r18 [$a2] = 40 $r19 [$a3] = 6 $r20 [$a4] = 0 $r21 [$a5] = 6 $r22 [$t8] = 4 $r23 [$t9] = 2 $r24 [$t10] = 1 $r25 [$t11] = 0 $r26 [$ra] = 4395904354148 $r27 [$t12] = 4395904050272 $r28 [$at] = 293938 $r29 [$gp] = 4396974651024 $r30 [$sp] = 4831834336 $r31 [$zero]= 0 $f0 = 0 $f1 = 0 $f2 = 0 $f3 = 0 $f4 = 0 $f5 = 0 $f6 = 0 $f7 = 0 $f8 = 0 $f9 = 0 $f10 = 3.237908616585193e-319 $f11 = 65536 $f12 = 0 $f13 = 0 $f14 = 1.016984725399622e-319 $f15 = 20584 $f16 = 0 $f17 = 0 $f18 = 0 $f19 = 0 $f20 = 0 $f21 = 0 $f22 = 3.237908616585193e-319 $f23 = 65536 $f24 = 0 $f25 = 0 $f26 = 0 $f27 = 0 $f28 = 0 $f29 = 0 $f30 = 0 $f31 = 0 $pc = 0x3ff8051df04 (ladebug) |
For a single thread core file, Ladebug will not show the kernel thread ID. |
This chapter describes the scripting features of the debugger. Using debugger script commands, you can specify a file to input as debugger commands, send debugger output to a file, or send a transcript of an entire debugging session to a file.
For more information on the Ladebug commands mentioned in this chapter,
see Part 5.
12.1 The Debugger Initialization File
When you start the debugger GUI, it first searches for the ladebugresource initialization file which is used to customize the Motif resources that the debugger uses. See Section 4.1.4 for more information on how to customize the ladebugresource initialization file.
Also at startup, the debugger engine searches for a file named .dbxinit in your home directory; if it is not there, it then searches for it in the current directory, and then the object directory of the executable image, if specified. If a .dbxinit file exists in either directory, the debugger interprets the contents of the file as a string of debugger commands. You can customize your debugger environment by adding commands to your .dbxinit file that set debugger aliases (using the alias command), debugger variables (using the set command), and source-code search paths (using the use command).
The debugger processes the .dbxinit file using the language of the main program being debugged. Depending on the language of that program, there are some situations where the behavior of some .dbxinit commands may vary. If this is an issue, you can put a set $lang command in the file to ensure the expected behavior.
Example 12-1 shows a sample .dbxinit file.
| Example 12-1 A Sample .dbxinit File |
|---|
set $listwindow = 45 alias ls "sh ls -l" stop in main; run |
When you invoke the debugger, it executes the commands in the .dbxinit file without echoing the commands to the screen. Example 12-2 shows this process for the sample .dbxinit file.
| Example 12-2 Debugger Startup Using a .dbxinit File |
|---|
% ladebug sample
Welcome to the Ladebug Debugger Version 4.0
------------------
object file name: sample
Reading symbolic information ...done
[#1: stop in main ]
[1] stopped at [main:4 0x1200001180]
4 for (i=1 ; i<3 ; i++) {
(ladebug)
|
You can record both your debugger commands as well as the debugger's responses into a single file by using the record io command. If a file already exists with the file name you specify, the debugger appends to the file.
You can record debugger responses to your commands using the record output command.
Use the record input command to create a file containing the commands you enter at the debugger prompt.
Use the record input command to create a debugger script. After creating a file containing a list of debugger commands, you can request that the debugger execute the commands in the file using the source command. You can also use an editor (such as vi or emacs) to edit the commands listed in the file. Example 12-3 shows how to use the record input command to record a series of debugger commands in a file named myscript.
| Example 12-3 Recording a Debugger Script |
|---|
(ladebug) record input myscript
(ladebug) stop in main
[#1: stop in main ]
(ladebug) run
[1] stopped at [main:4 0x120000b14]
4 for (i=1 ; i<3 ; i++) {
(ladebug) next
stopped at [main:5 0x120000b1c]
5 f = factorial(i);
(ladebug) step
stopped at [factorial:13 0x120000bb8]
13 if (i<=1)
(ladebug) where
>0 0x120000bb8 in factorial(i=1) sample.c:13
#1 0x120000b28 in main() sample.c:5
(ladebug) cont
1! = 1
2! = 2
Thread has finished executing
(ladebug) quit
% cat myscript
stop in main
run
next
step
where
cont
quit
%
|
With the source or playback input commands, you can read in and execute a file containing debugger commands. You can create such a file manually using an editor or automatically using the record input command.
Example 12-4 shows how to execute a debugger script. Because $pimode is set to 0, only the command output, and not the commands themselves, echoes to the display.
| Example 12-4 Executing a Debugger Script |
|---|
(ladebug) source myscript
[#1: stop in main ]
[1] stopped at [main:4 0x120000b14]
4 for (i=1 ; i<3 ; i++) {
stopped at [main:5 0x4001d4]
5 f = factorial(i);
stopped at [factorial:13 0x120000b1c]
13 if (i<=1)
>0 0x120000bb8 in factorial(i=1) sample.c:13
#1 0x120000b28 in main() sample.c:5
1! = 1
2! = 2
Thread has finished executing
%
|
| Previous | Next | Contents | Index |