A core dump is a file containing an image of a process’s memory at the moment it terminated. The core(5) manual page on Linux describes it precisely as a file containing an image of the process’s memory at the time of termination, written when certain signals cause a process to die abnormally. Because it preserves the program’s final state, the dump can be loaded into a debugger after the fact to investigate why the program crashed, without having to reproduce the failure live.
The name is a fossil from the hardware of an earlier era. The main memory of computers from the 1950s through the 1970s was built from magnetic-core memory, a grid of tiny ferrite rings each storing one bit. To dump core meant to write out the contents of that core memory. The technology disappeared decades ago, but the term survived: the file that captures a crashed program’s memory is still called a core dump, and the act of producing one is still called dumping core, even on machines whose memory is entirely semiconductor.
A core dump typically records the contents of the process’s address space, the values of its CPU registers at the point of failure, and metadata describing the program and the signal that killed it. From this, a debugger can reconstruct the call stack that was active when the crash occurred, show the source line where execution stopped, and let the developer examine the values of variables and memory exactly as they were at that instant. The GDB documentation describes the debugger’s role as letting a programmer see what a program was doing at the moment it crashed, which is precisely the post-mortem use of a core file together with the original executable.
Operating systems give the user considerable control over when and how core dumps are produced. The core(5) page documents the many conditions under which a dump is or is not written, including resource limits, file permissions, and security restrictions, and describes the core_pattern mechanism by which the kernel names the resulting file, using template specifiers such as the process ID, the executable name, and a timestamp. The pattern can even pipe the dump to a handler program rather than writing a file, which is how modern systems route crash data into automated collection and reporting services.
Core dumps remain a cornerstone of debugging deployed software. A program that fails in production, perhaps on a customer’s machine or a remote server where attaching a live debugger is impractical, can be configured to leave a core dump behind. A developer can then analyze that snapshot at leisure on another machine, turning a transient crash into a reproducible, inspectable artifact. The pairing of a saved core file with a source-level debugger such as GDB or LLDB is one of the oldest and most reliable techniques for diagnosing failures after the fact.