Generation & Analysing Cores Files or Core Dump

How to generate and analyse core dump in GDB

Core file or Core dump generation is a standard unix feature. A core file is simply a snap-shot of a running process’s memory at the time of generating the core. This is collected by the kernel when it decides to snap the process or task. You can consider this as memory photograph of a process in question. This is generated which process crashes or can be generated on user demand for various purposes example: debugging.
The core contains the memory contents of the process at the point of the seg-fault including its code segment, data segment, stack segment and heap segment. So, we can analyze why the particular crash happened.
This can be generated using following commands:
Kill –ABORT <pid>
Under GDB:
gcore <filename>, Or
generate-core-file <filename>
Parameters that control core file generation
In linux, we have
  • resource limits of the process
Every process has various limits associated with it. Read man setrlimit for these. Bash offers a built-in ulimit through which we can edit these. These control the limits of future process spawned from this bash-shell. Core-file max-size (ulimit -c/RLIMIT_CORE) controls the maximum core file size that can be generated when the process snaps.
  • kernel core file pattern.
Linux offers a proc file hook – /proc/sys/kernel/core_pattern, which contains the format for the name of the core-file. It allows using some format specifiers
 %p: pid
 %: '%' is dropped
 %%: output one '%'
 %u: uid
 %g: gid
 %s: signal number
 %t: UNIX time of dump
 %h: hostname
 %e: executable filename
 %: both are dropped
In addition using ‘/’ as part of the names helps to move the core-file location to a directory other than pwd (relative or absolute depending on if start is a ‘/’). In addition, if the patter starts with a pipe (‘|’), linux will pipe the core file into the stdin of the program that follows next! One can permanently set this in a linux machine by adding kernel.core_pattern in /etc/sysctl.conf.
# ulimit -c
0
If the output is 0, this suggest that core dump is disabled by default. Else, you will get resource limits using ‘ulimit –a’

Checking goodness of the core generated fine
LOGS

ubuntu@:~$ ulimit -c unlimited
ubuntu@:~$ ulimit -a
ubuntu@:~$ vim abc.c
ubuntu@:~$ gcc abc.c -o abc ubuntu@:~$ ./abc Segmentation fault (core dumped) ubuntu@:~$ ls abc  abc.c  core
At times due to various reasons core file corrupts and and GDB is not happy with it, to really validate this fact is is important to check the consistence of the core file:
Good Core file

<div>A corrupted core-file will give a different o/p with objdump and will give warnings when tested with readelf. The readelf check is usually more reliable than objdump.

ubuntu@:~$ objdump -a core
core:     file format elf64-x86-64
Core
ubuntu@:~$ readelf -a core 2>&1 | grep -i warn
ubuntu@:~$
If you have printable stings in your code like Version Number, Software Release, etc. You can print them to validate the correct version of core file you are debugging is like this:
ubuntu@:~$ strings abc | grep SW-VERSION
SW-VERSION=1.0
GDB
Make sure GDB doesn’t complain about the else it may give warning like “warning: exec file is newer than core file.” or something related to mismatch of core Vs executable.
Code debugging improves system understanding and its behavior, hence do it often even if you do not get crashes.