Examining core file

simple question, how do you go about examining a core file?  I received a segmentation fault violation and want to figure out where it happened w/in the code.

jeweeAsked:
Who is Participating?
 
avizitCommented:
Hmm personally speaking I prefer to debug by running the program once again rather than examining the core files.  But in cases where the bug is not reproducible you have no other way than to use  the core file.

First of all the program should be compiled with -g else theere is very little debugging info in the executable.

anyway to give a brief demo  Iwrote this very small test program ee.c

#include <stdio.h>
int main(){
 int a = 3;
int b = 4;

int c;
c = a + b;
c = c +1 ;
abort();
}
 compile this with the -g switch

gcc -g ee.c

and when you run you get core dump

so to examine it we type

gdb a.out core

and we get This GDB was configured as "i686-pc-linux-gnu"...
Core was generated by `./a.out'.
Program terminated with signal 6, Aborted.
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0  0x4004e381 in kill () from /lib/libc.so.6
(gdb)

to get to the exact line in our program which caused the abort youcan give the command up

so typing up one after another we get
(gdb) up
#1  0x4004e115 in raise () from /lib/libc.so.6
(gdb) up
#2  0x4004f66b in abort () from /lib/libc.so.6
(gdb) up
#3  0x08048369 in main () at ee.c:9
9       abort();


which gives us the line of our program  which caused the abort

down command is the exact opposite of up

you can type backtrace  or bt to get a back trace

in our case here is the result
(gdb) bt
#0  0x4004e381 in kill () from /lib/libc.so.6
#1  0x4004e115 in raise () from /lib/libc.so.6
#2  0x4004f66b in abort () from /lib/libc.so.6
#3  0x08048369 in main () at ee.c:9
#4  0x4003a90b in __libc_start_main () from /lib/libc.so.6


there can be many more commands , ( i know only these and I think they can be sufficient for you to get started )

/abhijit/




0
 
oumerCommented:
if you are used to emacs, then doing gdb within emacs will give you more user friendly displays.
Open your cpp file that contains the main
(ofcourse I assume you have compiled your program with -g flag.)
Then from the tools menu, choose debug and in the command line at the bottom
gdb "your executable name here" "core file name here"
and press enter
Now gdb will take you to the place where the segmentation error occured
you can do
bt
to see the flow of the commands that led to the place of error
then you can use
up
command to go up one leve up on the stack trace and see what parameters/variables are affected and so on ...

The advantage of using gdb within emacs is you see a split window where you see the gdb commands and output in one and your program source code on the other. If you just use command line gdb you may have to type once in a while "where" command to see where you are in the command, which, in my opinion, is quite boring....

0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.