Coder Perfect

The core has been dumped, but the core file isn’t located in the current directory?


It indicates “(core dumped)” when I start a C application, but I don’t see any files under the current directory.

I’ve set and double-checked the ulimit:

ulimit -c unlimited 
ulimit -a 

I also attempted to locate a file labeled “core,” but was unable to locate the core dumped file? I’m looking for my core file and can’t seem to find it.

Asked by

Solution #1

Read /usr/src/linux/Documentation/sysctl/kernel.txt.

Your system is set up to send the core dump to the abrt (automated Bug Reporting Tool, not “abort”) application instead of writing it to disk. It’s possible that the Automated Bug Reporting Tool isn’t as well documented as it should be…

In any case, you should be able to locate your core file in /var/cache/abrt, which is where abrt saves it after being launched. Similarly, other Apport-enabled systems may store cores in /var/crash, and so on.

Answered by ephemient

Solution #2

“Segmentation fault (core dumped)” can be printed on latest Ubuntu (12.04 in my situation), yet no core file is produced where you might expect one (for instance for a locally compiled program).

This can happen if your core file size ulimit is set to 0 (you haven’t done ulimit -c limitless), which is Ubuntu’s default. Normally, this would suppress the “(core dumped)” message, alerting you to your error. However, corefiles are piped to Apport (Ubuntu’s crash reporting system) via /proc/sys/kernel/core pattern on Ubuntu, and this appears to be the source of the false message.

If Apport determines that the program in question is not one for which it should be reporting crashes (as shown in /var/log/apport.log), it reverts to emulating the default kernel behavior of placing a core file in the cwd (as done in the /usr/share/apport/apport script). This includes respecting ulimit, in which case nothing happens. However, a corefile was produced (and fed to apport) in the kernel, resulting in the message “Segmentation fault (core spilled)”.

PEBKAC was ultimately to blame for neglecting to set ulimit, but the deceptive message left me wondering what was consuming my corefiles for a while.

(In addition, the man 5 core page in the core(5) manual is an excellent reference for where your core file ends up and why it might not be written.)

Answered by jtn

Solution #3

Another circumstance has emerged as a result of the debut of systemd. Systemd stores core dumps in its journal by default, which may be accessed with the systemd-coredumpctl command. The following is defined in the core pattern-file:

$ cat /proc/sys/kernel/core_pattern 
|/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e

Coredumpctl list is the simplest way to check for saved core dumps (older core dumps may have been removed automatically). A simple “hack” can be used to stop this behavior:

$ ln -s /dev/null /etc/sysctl.d/50-coredump.conf
$ sysctl -w kernel.core_pattern=core      # or just reboot

The size of core dumps must always be equal to or greater than the size of the core being dumped, as demonstrated by ulimit -c limitless.

Answered by timss

Solution #4

Writing instructions to get a core dump under Ubuntu 16.04 LTS:

Core dump – Oracle VM VirtualBox – Oracle VM VirtualBox – Oracle VM VirtualBox – Oracle VM VirtualBox – Oracle

Answered by ankurrc

Solution #5

There are two alternatives that come to mind:

Answered by ahans

Post is based on