# Cannot get core dump [SOLVED]

## mw007

Hello All,

I have enabled ELF core dumping in the kernel. After reading the documentation and searching the filesystem, I have not been able to find a core file that was generated; however, dmesg says that a segfault was reached in a daemon that was written by myself. Running in gdb is not an option in this case, as it could take days for a memory error to occur.

Could someone point me to the place where the core file would be placed?

Thanks,

mwLast edited by mw007 on Thu Jan 28, 2010 2:18 pm; edited 1 time in total

----------

## HeissFuss

It should go in the CWD.  Otherwise, check /proc/sys/kernel/core_pattern to see if another location is specified.

Also, if your user's ulimit for core file size is set to 0, no core will be generated.  Check with 'ulimit -c'.

----------

## mw007

 *HeissFuss wrote:*   

> It should go in the CWD.  Otherwise, check /proc/sys/kernel/core_pattern to see if another location is specified.
> 
> Also, if your user's ulimit for core file size is set to 0, no core will be generated.  Check with 'ulimit -c'.

 

I was under the impression that the `ulimit` command only applied to the current session? I have the ELF_CORE option enabled in the kernel to hopefully dump all cores. Or is that not possible?

I will check the core_pattern file and see if there is something set for it.

----------

## HeissFuss

It is my understanding that ELF_CORE still respects the calling processes' core size limit.  Unless you set RLIMIT_CORE, the ulimit soft core size will be used.  Also, RLIMIT_CORE has a max of the executing user's hard core size limit.  If you set the ulimit before executing your program, it should respect whatever your core size limit was at that time.

----------

## mw007

Oddly enough, RLIMIT_CORE is set to 4 (bytes) in /usr/include/bits/resource.h. I'm not sure where I should redefine this. Possibly in the daemon application, but I almost feel that should be separate from my code.

Also, this daemon is started as a system service in its own initscript. Not sure which session it would take the `ulimit` setting from. I could always add `ulimit -c unlimited` to .bashrc I suppose.

----------

## HeissFuss

If your process runs as root, you can either set root's soft core limit in /etc/security/limits.conf, or you could have your code set RLIMIT_CORE with setrlimit (I think that's the right way to do it.)

You can test that the limits are working by sending a core signal to your daemon (kill -11 or any other signal that generates cores.)

----------

## Hu

 *mw007 wrote:*   

> Oddly enough, RLIMIT_CORE is set to 4 (bytes) in /usr/include/bits/resource.h.

 I can see from the documentation why you thought this, but your interpretation is incorrect.  The correct reading is:

RLIMIT_CORE specifies the largest core file that can be generated, in bytes.  Should you wish to manipulate the resource limit, the numeric value to use in getrlimit and setrlimit is the magic number 4.  However, you should prefer the symbolic constant RLIMIT_CORE, so that your program works on other systems.

----------

## mw007

Thanks to everyone that has replied thus far.

I almost have this working. Here is what I've found.

You must edit the /etc/security/limits.conf and place the following line in there 

```
 *               soft    core            9999999 
```

 This will tell the kernel to log cores that are not bigger than 9,999,999 kilobytes. This is obviously changeable.

I then made a test program that contains an infinite loop. I then terminate the program with 

```
kill -11 <pid>
```

 A core is generated at this point.

However, using `kill -11 <pid>` on my daemon (which is not run from a session I've opened as it is run from an initscript), results in no core.

Thoughts on how to get this working so I can see exactly what's happening in the daemon? I'm not completely opposed to running the daemon in a terminal session, however I fear that certain environment conditions might change and affect the outcome.

Any insight is greatly appreciated.

----------

## Hu

As HeissFuss indicated in the first response, your problem is probably related to the current working directory.  Your daemon needs to be in a directory such that calling open() with the filename set to the value of /proc/sys/kernel/core_pattern and the flags set to O_CREAT | O_NOFOLLOW would succeed.  This is not actually how it is implemented internally, but is a fairly close approximation of the rules that are followed.  See man 5 core for a longer list of reasons why you might not get a core dump.

----------

## mw007

 *Hu wrote:*   

> As HeissFuss indicated in the first response, your problem is probably related to the current working directory.  Your daemon needs to be in a directory such that calling open() with the filename set to the value of /proc/sys/kernel/core_pattern and the flags set to O_CREAT | O_NOFOLLOW would succeed.  This is not actually how it is implemented internally, but is a fairly close approximation of the rules that are followed.  See man 5 core for a longer list of reasons why you might not get a core dump.

 

Thank you! This makes a lot more sense now. It didn't occur to me to search the manpages for core.

The reason I wasn't getting a core was because the current working directory of the daemon was not writable. So I used the pipe (|) operator in /proc/sys/kernel/core_pattern with a modified version of the example program in the core manpage to write the core to a specific directory that I knew was writable.

Also, for those finding this later and trying to get cores,  make absolute sure the program you are trying to get a dump for is compiled with debugging symbols . By default, they are not. See  'How to get meaningful backtraces in Gentoo'  for more info.

----------

