5

When a process dumps core, does it set any particular exit code? Alternatively, is there a way to detect if core was dumped in a shell script.

I have shell script that fires a job which occasionally dumps the core. If my job dumps the core, I would like to modify the shell script so that next lines can check status and inform others interested that the job dumped core.

We save core dumps and do analyse it. This right now is done by simple find command. If I can check if one of the lines in my shell script caused core dump, I can diagnose the problems much faster.

On ubuntu 12.04.

| improve this question | |
  • Aren't process core dumps usually disabled using the apprpriate ulimit shell varient these days? Prevents all that disk space being used by droppings of core files. – mdpc Aug 6 '14 at 2:16
5

In practice, a core dump will automatically be produced when the process is terminated by some signal, and the exit code will be determined by the signal (128 + signal_value), and under Linux, the signals can be at least: SIGQUIT (3), SIGILL (4), SIGABRT (6), SIGFPE (8), SIGSEGV (11). See the signal(7) man page for a more complete list. A core dump will not always be produced; see some circumstances in the core(5) man page.

Note: In languages that have full access to the wait system call (but this is not the case of POSIX shell scripts), you can use WCOREDUMP (available under Linux), which returns true if the child produced a core dump. See the wait(2) man page for more information.

| improve this answer | |
  • So if I check exit status above 128, chances are high that it might have dumped core? I know process it self can trap some signals, but key question is does the parent process (shell script) some how know child process crashed – user871199 Aug 6 '14 at 0:27
  • @user871199 No, because most signals, like for example SIGTERM, do not cause a core dump. But if you check for just those signals listed in the answer, then yes, chances are good the process dumped core. So for example, if $? is 131, indicating SIGQUIT, it dumped core. Couple this with a test to check whether core dumps are enabled at all (with ulimit) and you have a fairly reliable guess. There is a flag bit in the raw status value as reported to the shell by the kernel which allows you to determine with certainty whether a core dump occurred, but that bit is not reflected in $?. – Celada Aug 6 '14 at 0:32
  • @user871199 In a shell script, an exit satus above 128 generally means that the process has been terminated by the corresponding signal (however, for instance, sh -c 'exit 131' gives you something similar to a SIGQUIT, but no core dump). In some languages, you can have more information with the wait system call. – vinc17 Aug 6 '14 at 0:39
  • @vinc17,@Celada, Thanks for the explanation. In my case chances of someone terminating job are very low. Normally process terminates with status code 0. But when it dumps, its SIGSEGV, so I can use your answer. Might get few false alarms as you have indicated, but much better than nothing. – user871199 Aug 6 '14 at 0:45
  • @user871199 See the note I've added to my answer. I don't know whether this can be useful for you, e.g. by running child processes via a wrapper written in C/Perl/etc. – vinc17 Aug 6 '14 at 0:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.