c – Core dumped, but core file is not in the current directory?

The Question :

290 people think this question is useful

While running a C program, It says “(core dumped)” but I can’t see any files under the current path.

I have set and verified the ulimit:

ulimit -c unlimited 
ulimit -a 

I also tried to find a file named “core”, but didn’t get the core dumped file?
Any help, where is my core file?

The Question Comments :
  • Does the program invoke chdir at some point? If so, look there.
  • Does the program change its working directory? Look there.
  • I would search the entire harddrive for a recent file 😉
  • oops no its not there… I checked it ..program chdir to /mnt and / i checked both directories but could not find the file. I even did find / -name “*core.” even this didn’t show me the file. The program uses C + sqlite ,while inserting values it core dumps It said assertion error==0 for the first time and error=101 for the second time..
  • Yes, if you override /proc/sys/kernel/core_pattern with a string starting with /tmp then that’s where your core dumps will go.

The Answer 1

250 people think this answer is useful

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

[/proc/sys/kernel/]core_pattern is used to specify a core dumpfile pattern name.

  • If the first character of the pattern is a ‘|’, the kernel will treat the rest of the pattern as a command to run. The core dump will be written to the standard input of that program instead of to a file.

Instead of writing the core dump to disk, your system is configured to send it to the abrt program instead. Automated Bug Reporting Tool is possibly not as documented as it should be…

In any case, the quick answer is that you should be able to find your core file in /var/cache/abrt, where abrt stores it after being invoked. Similarly, other systems using Apport may squirrel away cores in /var/crash, and so on.

The Answer 2

238 people think this answer is useful

On recent Ubuntu (12.04 in my case), it’s possible for “Segmentation fault (core dumped)” to be printed, but no core file produced where you might expect one (for instance for a locally compiled program).

This can happen if you have a core file size ulimit of 0 (you haven’t done ulimit -c unlimited) — this is the default on Ubuntu. Normally that would suppress the “(core dumped)”, cluing you into your mistake, but on Ubuntu, corefiles are piped to Apport (Ubuntu’s crash reporting system) via /proc/sys/kernel/core_pattern, and this seems to cause the misleading message.

If Apport discovers that the program in question is not one it should be reporting crashes for (which you can see happening in /var/log/apport.log), it falls back to simulating the default kernel behaviour of putting a core file in the cwd (this is done in the script /usr/share/apport/apport). This includes honouring ulimit, in which case it does nothing. But (I assume) as far as the kernel is concerned, a corefile was generated (and piped to apport), hence the message “Segmentation fault (core dumped)”.

Ultimately PEBKAC for forgetting to set ulimit, but the misleading message had me thinking I was going mad for a while, wondering what was eating my corefiles.

(Also, in general, the core(5) manual page — man 5 core — is a good reference for where your core file ends up and reasons it might not be written.)

The Answer 3

83 people think this answer is useful

With the launch of systemd, there’s another scenario aswell. By default systemd will store core dumps in its journal, being accessible with the systemd-coredumpctl command. Defined in the core_pattern-file:

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

This behaviour can be disabled with a simple “hack”:

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

As always, the size of core dumps has to be equal or higher than the size of the core that is being dumped, as done by for example ulimit -c unlimited.

The Answer 4

56 people think this answer is useful

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

  1. As @jtn has mentioned in his answer, Ubuntu delegates the display of crashes to apport, which in turn refuses to write the dump because the program is not an installed package. Before making changes

  2. To remedy the problem, we need to make sure apport writes core dump files for non-package programs as well. To do so, create a file named ~/.config/apport/settings with the following contents:
    [main] unpackaged=true

  3. Now crash your program again, and see your crash files being generated within folder: /var/crash with names like *.1000.crash. Note that these files cannot be read by gdb directly. After making changes
  4. [Optional] To make the dumps readble by gdb, run the following command:

    apport-unpack <location_of_report> <target_directory>

References: Core_dump – Oracle VM VirtualBox

The Answer 5

12 people think this answer is useful

I could think of two following possibilities:

  1. As others have already pointed out, the program might chdir(). Is the user running the program allowed to write into the directory it chdir()‘ed to? If not, it cannot create the core dump.

  2. For some weird reason the core dump isn’t named core.* You can check /proc/sys/kernel/core_pattern for that. Also, the find command you named wouldn’t find a typical core dump. You should use find / -name "*core.*", as the typical name of the coredump is core.$PID

The Answer 6

9 people think this answer is useful

If you’re missing core dumps for binaries on RHEL and when using abrt, make sure that /etc/abrt/abrt-action-save-package-data.conf

contains

ProcessUnpackaged = yes

This enables the creation of crash reports (including core dumps) for binaries which are not part of installed packages (e.g. locally built).

The Answer 7

7 people think this answer is useful

In Ubuntu18.04, the most easist way to get a core file is inputing the command below to stop the apport service.

sudo service apport stop

Then rerun the application, you will get dump file in current directory.

The Answer 8

6 people think this answer is useful

For fedora25, I could find core file at

/var/spool/abrt/ccpp-2017-02-16-16:36:51-2974/coredump

where ccpp-2017-02-16-16:36:51-2974" is pattern "%s %c %p %u %g %t %P % as per `/proc/sys/kernel/core_pattern’

The Answer 9

5 people think this answer is useful

My efforts in WSL have been unsuccessful.

For those running on Windows Subsystem for Linux (WSL) there seems to be an open issue at this time for missing core dump files.

The comments indicate that

This is a known issue that we are aware of, it is something we are investigating.

Github issue

Windows Developer Feedback

The Answer 10

3 people think this answer is useful

I’m on Linux Mint 19 (Ubuntu 18 based). I wanted to have coredump files in current folder. I had to do two things:

  1. Change /proc/sys/kernel/core_pattern (by # echo "core.%p.%s.%c.%d.%P > /proc/sys/kernel/core_pattern or by # sysctl -w kernel.core_pattern=core.%p.%s.%c.%d.%P)
  2. Raising limit for core file size by $ ulimit -c unlimited

That was written already in the answers, but I wrote to summarize succinctly. Interestingly changing limit did not require root privileges (as per https://askubuntu.com/questions/162229/how-do-i-increase-the-open-files-limit-for-a-non-root-user non-root can only lower the limit, so that was unexpected – comments about it are welcome).

The Answer 11

2 people think this answer is useful

ulimit -c unlimited made the core file correctly appear in the current directory after a “core dumped”.

The Answer 12

0 people think this answer is useful

If you use Fedora, in order to generate core dump file in the same directory of binary file:

echo "core.%e.%p" > /proc/sys/kernel/core_pattern

And

ulimit -c unlimited

Add a Comment