Core dump functionality is a standard feature of Linux and other Unix-like operating systems. However, the creation of core files in every case is not practical. Since core files are snapshots of process memory, they can account for megabytes or even gigabytes on a filesystem. In many cases, this is not acceptable.

Developers need to explicitly specify the maximum size of the core files that are allowed to be generated by the operating system. This limit, among other limits, can be set using the ulimit command.

We run ulimit twice to remove the limit first for the superuser root, and then for the ordinary user/developer. The two-stage process is needed because the ordinary user limit cannot exceed the superuser limit.

After we have removed the limit for the core file size, we run our test application without the GDB. It crashes, as expected. After the crash, we can see that a new file called core was created in the current directory. 

When we run our application, it crashes. Normally, we would not be able to track the root cause of the crash. However, since we enabled core dumps, a file named core was automatically created for us by the operating system:

A core file is a binary dump of all process memory, but it is difficult to analyze it without additional tools. Thankfully, the GDB provides the necessary support. 

We run the GDB passing two parameters – the path to the executable, and the path to the core file. In this mode, we do not run the application from inside the GDB. We already have its state frozen at the moment of the crash in the core dump. The GDB uses the executable to bind memory addressed within the core file to functions and variable names:

As a result, you can analyze the crashed application in an interactive debugger, even when the application was not run from the debugger. When we invoke the bt command, the GDB displays the stack trace at the moment of the crash:

This way, we can nail down the root cause of an application crashing even if, initially, it was not run in a debugger.