When the operating system encounters an unrecoverable error, for example, a segmentation violation (SEGV), 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 process at the time the error occurred. It allows you to analyze the process at the point it crashed.
You can use the debugger to examine the process information in a core file. Use the following debugger command syntax to invoke the debugger on a core file:
% idb executable_file core_file
or
(idb) load executable_file core_file
The executable file is that which was being executed at the time the core file was generated.
When debugging a core file, you can use the debugger to obtain a stack trace and the values of some variables just as you would for a stopped process.
The stack trace lists the functions in your program that were active when the dump occurred. By examining the values of a few variables along with the stack trace, you may be able to pinpoint the process state and the cause of the core dump. Core files cannot be executed; therefore the rerun, step, cont and so on commands will not work until you create a process using the run command.
In addition, if the program is multithreaded, you can examine the thread information with the show thread and thread commands. You can examine the stack trace for a particular thread or for all threads with the where thread command.
The following example uses a null pointer reference in the factorial function. This reference causes the process to abort and dump the core when it is executed. In GDB mode, 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.
% cat testProgram.c
#include <stdio.h>
int factorial(int i)
main() {
int i,f;
for (i=1 ; i<3 ; i++) {
f = factorial(i);
printf("%d! = %d\en",i,f);
}
}
int factorial(int 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.
% idb testProgram core
Welcome to the debugger Version n
------------------
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
(idb) where
>0 0x120000dc4 in factorial(i=1) testProgram.c:13
#1 0x120000d44 in main() testProgram.c:4
(idb) dump
>0 0x120000dc4 in factorial(i=1) testProgram.c:13
printf("%d",*x);
(idb) print *x
Cannot dereference 0x0
Error: no value for *x
(idb)
Transporting core files is usually necessary to debug a core file on a system other than that which produced it. It is sometimes possible to debug a core file on a system other than that which produced it if the current system is sufficiently similar to the original system, but it will not work correctly in general.
When moving core files, don't forget to move the original executable and any shared components it required.
If the POSIX Threads Library is involved, set the LD_LIBRARY_PATH environment variable to the debugger subdirectory so that the debugger will use the correct libpthreaddebug.so.
% env IDB_COREFILE_LIBRARY_PATH=applibs \
LD_LIBRARY_PATH=dbglibs \
idb a.out core