Core Dump - WTH is my core file?

“In sooth, I know not why I am so sad: It wearies me; you say it wearies you; But how I caught it…“

Thanks Shakespeare that’ll be all. Very often you’re greeted by this lovely message Segmentation Fault

All the youtube videos we’ve scrolled ask us to look for the core file to debug. Except that we don’t know where it is. Spoiler: hips don’t lie but operating systems do. It isn’t actually dumping it to memory and for good reasons. A core file is (very) expensive memory wise. It stores information about the program’s state right before crashing and depending on the complexity things can get bulky. Wanna check what’s the limit of core files that’s allowed for our session? Run

ulimit -c

Did we see a zero? That explains the size of core file processes started by us. We will get back to setting the size limit later.

First, understand that core files are saved with a name pattern attached to them. Checkout the contents of “core_pattern”

cat /proc/sys/kernel/core_pattern
|/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -F%F -- %E

We can figure out the pattern later. Apport is a service that thy precious’s system (Ubuntu) uses to report crashes. We can figure out how to disable that in a ChatGPT query. Lets edit the contents to something more simple for now.

sudo echo "core" >/proc/sys/kernel/core_pattern

This will dump core files with the name “core” right where we executed our executable. There is just one last tweak that we need to do. Remember our size allocated for core files was 0? Let’s make it unlimited with

ulimit -c unlimited

Append this line to the bottom of your bash shell’s “run control” file: ~/.bashrc

nano ~/.bashrc
# <perform edits and save>
source ~/.bashrc

source helps us load any aliases, environment variables or settings that we want our terminal to start from. If we’re using another shell like zsh then we will be editing its rc file (~/.zshrc)

Judgement Day

Now is the time to write a buggy program. Thy precious recommends we use cpplayout to quickly setup a C++ project. Let’s quickly compile the following buggy code with debug flag:

#include <iostream>

int main()
{
	int *ptr = NULL;
	std::cout << *ptr;
	return 0;
}

g++ -g main.cpp -o program_bin

We can now run our program and watch it yield a segmentation fault with delight. Let’s look at the core file with GDB.

gdb -c ./core ./program_bin
# <enter GDB session and find the bug>
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00005d81a948f161 in main () at main.cpp:6
6 std::cout << *ptr;

It has been revealed that dereferencing a nullptr is not a good idea. This debug info was possible because of -g flag. Read up on debugging with GDB next.

More on debugging with core dumps

The party is only getting started. We have noticed that core files are huge and production systems often rerun their BOD (beginning of day) script which can overwrite existing core files. We can do a quick ChatGPT session again to figure out saving the core file name with PID and timestamp.

Now that the setup guarantees we get our core files, we can go back to learning from YouTube tutorials. Thy precious recommends Jacob Sorber’s playlist among other good resources.

Keyboard shortcuts

C++

Core Dump - WTH is my core file?