Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

Tags:

c

linux

coredump

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?

like image 635
webminal.org Avatar asked Jan 14 '10 16:01

webminal.org


People also ask

Where do my core dumps go?

By default, all core dumps are stored in /var/lib/systemd/coredump (due to Storage=external ) and they are compressed with zstd (due to Compress=yes ). Additionally, various size limits for the storage can be configured. Note: The default value for kernel. core_pattern is set in /usr/lib/sysctl.

Where is the core file in Linux?

On Linux operating systems, core files are, by default, named "core" and are located in the working directory of the application which faulted. In the case of TM1, this is usually the tm1/bin64 directory.

Where is core dump file in Ubuntu?

In Ubuntu the core dumps are handled by Apport and can be located in /var/crash/. But it is disabled by default in stable releases.


2 Answers

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

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 (meaning: Automated Bug Reporting Tool, not "abort") 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.

like image 52
ephemient Avatar answered Nov 03 '22 08:11

ephemient


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.)

like image 39
jtn Avatar answered Nov 03 '22 07:11

jtn