a core dump and post-mortem debugging
Sometimes a program crashes and you were not watching - it died at 3 a.m. on a server, or it only fails once in a thousand runs and you cannot catch it live. It would help enormously to have a snapshot of the exact moment of death: every variable, the call stack, the values in registers, frozen as they were. A core dump is precisely that snapshot. When a program crashes badly, the operating system can write the contents of its memory and CPU state to a file called a core (or 'core dump'), preserving the corpse for you to examine later.
Concretely, when a process hits a fatal fault - a segmentation fault, an abort, an illegal instruction - the kernel may, if configured to, dump the process's address space and register state into a file (often named 'core' or 'core.PID'). Later you do post-mortem debugging: you load that core into a debugger together with the original executable - in gdb, 'gdb ./program core' - and the debugger reconstructs the scene as if the crash just happened. You cannot step forward (the program is dead and frozen), but you can do everything else read-only: 'bt' for the backtrace that led to the crash, 'print' to inspect variables, examine memory, and walk the frames to find the bad value. It is an autopsy: full information about the moment of death, but no continuing the patient.
Why it matters: core dumps turn unwatchable, intermittent, or production crashes into investigable evidence - you do not need to reproduce the bug live, you just need the corpse and the matching binary built with debug info. Honest caveats: dumps are often disabled by default and capped by a resource limit (on Linux 'ulimit -c unlimited' enables them), so you may get nothing unless you turned them on beforehand; a core matched to the wrong or optimized binary gives misleading or symbol-less results; and a core can be large (it is the whole memory image) and may contain sensitive data, so handle it carefully.
$ ulimit -c unlimited then run the program until it segfaults, producing a file named core. Then $ gdb ./program core and inside, bt shows the call stack at the moment of death and print reveals the variables - all without ever reproducing the crash again.
A core file plus the binary lets you autopsy a crash you never saw happen.
Core dumps are commonly disabled by default (a zero size limit) and may be redirected by the OS, so a crash can leave no core at all unless you enabled it first. A core only makes sense paired with the exact binary that produced it, ideally one built with -g.