7

I have an issue where my application keeps on dumping core after few day/weeks, but unfortunately, generates no core dump.

We tried to set ulimit -c unlimited with no success, so we incorporated setrlimit functionality in the code itself, but had no luck with that approach either. And, on top of that, we added MALLOC_CHECK_ too.

Interestingly, when we tried to initiate a manual core dump (using kill -ABRT <pid>), it did generate a core dump.

I could see the following message in /var/log/message

kernel: [2302077.396021] myapp[22140]: segfault at 54552e42 ip 00000000f773f36f sp 00000000fffdc48c error 4 in ld-2.11.3.so[f7727000+1f000]

Environment: sles11

Any suggestions on how to make the application generate core dumps more reliably?

Philip Conrad
  • 1,451
  • 1
  • 13
  • 22
Thangaraj
  • 3,038
  • 7
  • 40
  • 43
  • Compile your code using the options `-Wall -g`. Fix it until no more warnings are issued. Before starting it call `ulimit -c unlimited` from the shell. Call `ulimit -a` for info. – alk Jan 16 '13 at 07:42
  • 1
    The obvious reason for not writing the core to disk would be lack of disk space. Another would be that the directory did not exist. As for the reason for crashing, I would guess there is some kind of resource leak. The most common resource leaks are memory leaks and file handle leeks. – Klas Lindbäck Jan 16 '13 at 08:02
  • @alk, we compiled the code with -g flag. We tried ulimit -c unlimited as well but no luck. After we tried all these things only we moved to setrlimit approach. – Thangaraj Jan 16 '13 at 08:27
  • @KlasLindbäck We could able to generate core using kill -ABRT , so I hope environment should not be an issue. – Thangaraj Jan 16 '13 at 08:31
  • You have verified that the process can create a core. That is good, cause that means you can tick off many of the reasons why you don't get one. The only other thing I can think of is that the signal that kills the process is one that doesn't create a core dump. I found a list for Mac OS/X here: http://www.manpagez.com/man/2/sigaction/. My google karma didn't find one for Linux, but maybe your karma is better (or at least you have incentive to spend more time finding one). – Klas Lindbäck Jan 16 '13 at 08:49

2 Answers2

4

Many current systems are configured so they don't leave core dumps (the average user doesn't know what to do with them).

  • Make sure you start the process where it can dump core (writable directory, enough space; I'm not sure if a directory change in the process might interfere here)
  • Make sure to give the "ulimit -c unlimited" in the same shell starting the process
  • If the program is SUID or SGID, the kernel will refuse to make it dump core for security reasons, take a look at this question for guidance
Community
  • 1
  • 1
vonbrand
  • 11,412
  • 8
  • 32
  • 52
  • 1
    Also worth checking the file /proc/sys/kernal/core_pattern to see where the corefiles will be put. /etc/sysctl.conf has a similar one but can be set more permanently. – kbickar Mar 10 '14 at 21:13
0

I just had the same problem with SLES 11. In addition to the advice given, in particular setting "ulimit -c unlimited", you need a couple more things:

  1. Modify /etc/security/limits.conf to add the following line. Then log off and on again just to be sure.

    *               soft    core            unlimited

  2. The default kernel core pattern is "/var/log/cores/%e/%p-%s-%t.core". (See core(5).) Linux won't create a core file if the directory part doesn't exist. So you need to create the "%e" bit, which is the name of your binary, or you could change the pattern.

Ben C
  • 658
  • 6
  • 18