Shell – Exit status on core dump

core-dumpshell-script

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.

Best Answer

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.

Related Solutions

Linux – core dump — linux

When a userland program crashes, it can leave a core file behind, containig a copy of the contents of the memory when it went down (the core name comes from the prehistory of computing, when memory was core). This is controlled by the ulimit(1) command, it is normally disabled as the core files are large and tend to confuse newbies. A core file can be analyzed by e.g. a debugger, together with the executable and symbol table, to find out what happened.

When the kernel crashes, it normally triggers a kernel panic. If the kernel has found some critical inconsistency, it really isn't wise to count on it bahaving sanely to write out anything. So no core gets generated, and the system goes down. Contents of registers and code surrounding the address where the problem happened is written to the console. It is a good idea to save this (e.g. take a picture) for possible later analysis.

A similar situation is the kernel Oops, when the kernel detects an inconsistency that isn't considered fatal. In that case (as in a kernel panic) contents of registers and code surrounding the address where the problem happened is written to the console, and also logged.

Bash – How to find why a bash exits with signal 11, Segmentation fault

I installed the debuginfo tools as suggested by gdb and then I got the expression responsible for the crash:

#20 0x0000000000457ac8 in expand_compound_array_assignment (
    var=<value optimized out>, 
    value=0x150c660 "$(logPath \"$@\")", flags=<value optimized out>
)

So now I know what and where is the issue. In my case it was in a function sourced in the .bashrc and the root cause was this wrong redefinition of the map variables in Bash:

declare -A myMap
local myMap=""

...
for key in "${!myMap[@]}"; do 
  echo ${myMap[$key]}
done

This function was called inside a sub-shell which caused the 'segmentation fault' error output to be hidden.

Best Answer

Related Solutions

Linux – core dump — linux

Bash – How to find why a bash exits with signal 11, Segmentation fault

Related Question