How to generate a core dump file in Gentoo Linux

Advantages of generating dump files over common debugging technologies:

1. It can capture bugs that cannot be reproduced or are difficult to reproduce;

2. Large programs and programs controlled by a large number of threads are very slow or difficult to debug with GDB.

Core Dumps

Sometimes the crashes are difficult to reproduce, the program is vastly threaded, it's too slow to run in GDB or it's messed up when run through it (shouldn't surprise anybody that running inside the debugger there are more bugs than are reproduceable without the debugger itself ). in these cases, there is one tool that comes in useful: the core dump.

A core dump is a file that contains the whole memory area of a program when it crashed. using that file, it's possible to extract the stack backtrace even if the program has crashed outside GDB, assuming core dumps are enabled. by default core dumps are not enabled on Gentoo Linux (they are, however, enabled by default on Gentoo/FreeBSD), so you have to enable them.

Core dumps can be enabled on the system level or the shell session level. in the first case, everything in the system that crashes and does not have already a crash handler (see later for more notes about KDE's crash handler) will dump. when enabled at Shell session level, only the programs started from that session will leave behind a dump.

To enable core dumps on a system level, you have to edit either/etc/security/limits. conf (if you're using PAM, as is the default) or/etc/limits. conf. in the first case, you must define a limit (whether hard or, most commonly, soft; for core files, that might be anywhere from 0 to no limit ). in the latter case, you just need to set the variable C to the size limit of a core file (here there's no "unlimited ").

Code listing 1.5: Example of rule to get unlimited core files when using PAM

# /etc/security/limits.conf * soft core 0

Code listing 1.6: Example of rule to get core files up to 20 mb when not using PAM

# /etc/limits.conf * C20480

To enable core files on a single shell session you can use the ulimit command with the-C option. 0 means disabled; Any other positive number is the size in KB of the generated core file, while unlimited simply removes the limit on Core File dimension. from that point on, all the programs that exit because of a signal like SIGABRT or SIGSEGV will leave behind a core file that might be called either "core" or "core. PID "(where PID is replaced with the actual PID of the program that died ).

Code listing 1.7: Example of ulimit use

$ ulimit -c unlimited $ crashing-program [...] Abort (Core Dumped) $

Note:The ulimit command is an internal command in bash and zsh. On other shells it might be called in other ways or might even not be available at all.

After you get a core dump, you can run GDB on it, specifying both the path to the file that generated the core dump (it has to be the same exact binary, so if you recompile, the core dump is useless) and the path to the core file. once you have GDB open on it, you can follow the same instructions given abve as it had just encrypted ed the signal killing it.

Code listing 1.8: Starting GDB on a core file

$ gdb $(which crashing-program) --core core

As an alternative, you can use GDB's command-line capabilities to get the backtrace without entering the interactive mode. this also makes it easier to save the backtrace in a file or to send it to a pipe of any kind. the trick lies in the -- batch and-Ex options that are accepted by GDB. you can use the following bash function to get the full backtrace of a core dump (including all threads) on the standard output stream.

Code listing 1.9: function to get the whole backtrace out of a core dump

gdb_get_backtrace() { local exe=$1 local core=$2 gdb ${exe} / --core ${core} / --batch / --quiet / -ex "thread apply all bt full" / -ex "quit" }