On many
Unix systems, when a program
crashes (usually due to a
Segmentation Fault or some other form of memory access error), the default behaviour is to dump the entire contents of the
memory the process was using to a
file on
disk. This is usually named something along the lines of "program_name.core" or just simply "
core".
To most people this is quite useless. With the typical sizes of many program nowadays, these dumps can be very large and take up an annoyingly large amount of space (especially if you have a home filestore with a quota and something like netscape coredumps). On Linux systems you can set the maximum size of core files with the ulimit command, eg.
$ ulimit -c 0
Will disable coredumps (setting the maximum size to 0). To enable them, set the limit to some fairly large value, eg.
$ ulimit -c 1000
Core files are actually useful to programmers. The contents of memory including the stack are included in the core, enabling the programmer to find exactly where the program crashed. You can load the core file using a debugger such as gdb:
$ gdb program_name core
GNU gdb 5.2.90_2002-11-20-cvs-debian
Copyright 2002 Free Software Foundation, Inc.
....
#0 0x080483b4 in func_1 ()
(gdb)
From here you can browse the stack. If you have debugging symbols compiled into the binary you will get the function names which helps greatly:
#0 0x080483b4 in func_1 ()
(gdb) up
#1 0x080483c7 in func_2 ()
(gdb) up
#2 0x080483d7 in func_3 ()
(gdb) up
#3 0x080483e7 in main ()
(gdb) up
#4 0x40039a5f in __libc_start_main () from /lib/libc.so.6
(gdb) up
Initial frame selected; you cannot go up.
(gdb)
You can of course disassemble the functions and find exactly where the crash occurs, but I wont go into a full explanation of how to use gdb as that belongs elsewhere. Personally I find that knowing what function it occurred in is usually enough information to locate the bug.