Core Dump : part 1

Well ...if u spend significant time on learning one language and slowly slowly or quickly depending on how much you are interested in that language ..you will try to see its different facets of that language.

So since I mostly work on C, I use to see lot of segmentation fault happening when writing program related to pointers or stackoverflow.  In all these cases COREDUMPS are generated, which tells memory wise what went wrong.

Now , mostly I don't use to see this, but go back to program and try to figure out what went wrong.

This works if your program is 1-2 files only and simple. Else its very hard to know why crash happened.

So i started to read about how to check core-dump in gcc.

Below is what i learned.

1) Is core dump getting generated ? 

Even though your gcc will say core dump is generated, but you will see it is not present. It happens because your SHELL doesn't have permission to generated coredump by default.

hence you have to run below command.

> ulimit -c unlimited.

NOTE : ulimit is shell property, so when you start running your program you have to run above cmd first. So any program then run on that will generate core dump.

2) Checking Core Dump#

1) Run below cmd :  
> gdb <executable> <core-file> or gdb <executable> -c <core-file>

Example I have c file name crash.c and core dump generated name is core, so i will run

> gdb ./crash core

This will give some information on my screen.

My .c program was

#include<stdio.h> #include<stdlib.h> int main() { int p[0]; int b=10; p[0];//=(int*) malloc(sizeof(int)*1); printf("b %d\n",b); printf("%p %p %p",&b,&p[0],&p[1]); p[1]=20; printf("b %d\n",b); free(p); // This is point where crash should occur //p=&b; }


Output of running cmd which mentioned below is

Core was generated by `./crash'. Program terminated with signal SIGABRT, Aborted. #0 0xb76df424 in __kernel_vsyscall ()







So as you can see with above message, you cannot do any shit with your program. Hence you have to use gdb next command -- bt . It stands for backtrace and prints the stack of program.




when i run bt below thing I got




(gdb) bt

#0  0xb76df424 in __kernel_vsyscall ()

#1  0xb7548827 in __GI_raise (sig=sig@entry=6)

    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56

#2  0xb754bc53 in __GI_abort () at abort.c:89

#3  0xb7583993 in __libc_message (do_abort=do_abort@entry=1, 

    fmt=fmt@entry=0xb7680a5c "*** Error in `%s': %s: 0x%s ***\n")

    at ../sysdeps/posix/libc_fatal.c:175

#4  0xb758de7a in malloc_printerr (action=<optimized out>, 

    str=0xb767c56d "free(): invalid pointer", ptr=0xbf7fc108)

    at malloc.c:4996

#5  0xb758eaed in _int_free (av=0xb76c5420 <main_arena>, 

    p=<optimized out>, have_lock=0) at malloc.c:3840

#6  0x080484c1 in main ()

As you can see, something makes a bit sense now.

Since stack is LIFO, the first line ( from last) tells as what was function entered in which we had crash, it was MAIN().

now, when we called free, it defination would hav been in malloc.c , since it is pointed next.

Line 4 is telling as 'free() : invalid pointer' so we can see our pointer there and can see that it is not correct.

Voila our program is debugged. In next tute , we will see more better code.