This post will demonstrate a way of obtaining and examining a core dump on Fedora Linux.
A Core file is a snapshot of working memory of some process. Normally there’s not much use for such a thing, but when it comes to debugging software it’s more than useful. Especially for those hard-to-reproduce random bugs. When your program crashes in such a way, it might be your only source of information, since the problem doesn’t need to come up in the next million executions of your application.
The thing is, creation of core dumps is disabled by default in Fedora, which is fine since the user doesn’t want to have some magic file spawned in his home folder every time an app goes down. But we’re here to fix stuff, so how do you turn it on? Well, there’s couple of thing that might prevent the cores to appear.
First, make sure that the program has writing permission for the directory it resides in. The core files are created in the directory of the executable. From my experience, core dump creation doesn’t work on programs executed from NTFS drives mounted through ntfs3g.
This is the place where the core dump creation is disabled. You can see for
yourself by using the
ulimit command in bash:
To enable core dumps set some reasonable size for core files. I usually opt for unlimited, since disk space is not an issue for me:
This setting is local only for the current shell though. To keep this
settings, you need to put the above line into your
~/.bashrc or (which is
cleaner) adjust the limits in
3. Ruling out ABRT
In Fedora, cores are sent to the Automatic Bug Reporting Tool – ABRT. So
they can be posted to the RedHat bugzilla to the developers to analyse. The
kernel is configured so that all core dumps are pipelined right to abrt. This
is set in
/proc/sys/kernel/core_pattern . My settings look like this
That means, that all core files are passed to the standard input of abrt-hook-ccpp. Change this settings simply to “core” i.e.:
Then the core files will be stored in the same directory as the executable and will be called core.PID.
4. Send Right Signals
Not every process termination leads to dumping core. Keep in mind, that core file will be created only if the process receives this signals: - SIGSEGV - SIGFPE - SIGABRT - SIGILL - SIGQUIT
Here’s a series of steps to test whether your configuration is valid and the cores will appear where they should. You can use this simple program to test it:
Compile the source, run the program and send a signal like following to get a memory dump:
Analysing Core Files
If you already have a core, you can open it using GNU Debugger (gdb). For instance, to open the core file, that was created earlier in this post and displaying a backtrace, do the following: