Core dump analysis is important in debugging sporadic crashes, usually resulting from memory misuse. If properly configured, some fatal signals that results in unexpected process termination will create core dumps. Full list of signals causing a core dump may be seen at http://man7.org/linux/man-pages/man7/signal.7.html, but most probable ones will be as follows;

core file analysis - signal values

Looking at the list most familiar one will be ”SIGSEGV”.

Now let’s check user limits about system resources using ”ulimit -a”, which will display all user limits.

core file analysis - ulimit
The important part is ”ulimit -c” for core file size, which is ”0” in our case, meaning there will be effectively no core dumps. Other important feature is about number of files, ”ulimit -n” , which may be important when handling many files simultaneously.

Implement a small program causing a segmentation fault.

core file analysis - simple segfault program code

Run this program to see it’s crash without a core dump.

core file analysis - simple segfault program run

In order to enable core dumps, edit ”/etc/security/limits.conf” to include * soft core unlimited line which enables unlimited file sized soft core files for all domains. We may specify a limit in KB instead of ”unlimited” identifier, but in practice this should never be an issue, cores ‘ll be small.

core file analysis - modifying etc security limits

Changes will be effective with new session / login. Check the new value of core size

core file analysis - ulimit after change

And recreate a segmentation fault with running executable above.

core file analysis - simple segfault program run after change

Now we have a core file to work on. Notice that newly generated cores will override the previous one, and directory for core is the working directory of the executable. In order to have better control on naming, we should modify ”/etc/sysctl.conf”

core file analysis - core file options and location

core file analysis - core options

In order to make changes effective we should run ”sysctl -p” which should make reading newly added variables. Then create segmentation fault again (two times).

core file analysis - simple segfault program run with options and location

Now we have more informative core files, located at ”/tmp” folder. Let’s see one of them using gdb;

core file analysis - gdb usage first run

If we have compiled the ”coretest.cpp” with debug symbols, using ”g++ -g coretest.cpp -o coretest”, we would have more information about the segmentation fault as seen below;
Actually problem is line 6 of main, where we have assignment to an uninitialized pointer.

core file analysis - gdb usage second run