Core dumps capture the program's memory at the moment of a crash. Load a core dump in GDB to inspect the crash stack and variables without attaching beforehand or re-running the program.
ulimit -c unlimited # enable core dumps (bash/zsh) ./program # crash produces core.PID in current dir gdb ./program core.1234 # load crash into GDB (gdb) backtrace # show stack at crash (gdb) frame 0 # inspect innermost frame (gdb) info locals # show variables at crash (gdb) print errno # show error code
By default, the shell does not save core dumps (ulimit -c is often 0). Set it to unlimited to enable them. A crash then creates a file core.PID (or just core) in the current directory. This file contains the full memory image at the crash.
Load the core dump with gdb ./binary core.PID. GDB shows the crash location as if you had hit a breakpoint there. Backtrace shows the exact call chain. Inspect variables in each frame to understand what went wrong. Unlike live debugging, you cannot step or continue—a core dump is post-mortem.
Core files can be large (often hundreds of MB) and may fill your filesystem. Consider disabling them after debugging, or set a smaller limit.
Alternatively, attach to a running process and set breakpoints before it crashes:
gdb -p PID # attach to process (gdb) catch signal SIGSEGV # pause on segmentation fault (gdb) continue # wait for crash
catch signal SIGNAME pauses execution when a signal is raised. Use SIGSEGV (segfault), SIGABRT (abort), SIGFPE (arithmetic error), etc. The program pauses instead of crashing, letting you inspect state.
Core dumps are invaluable for production debugging—save them when possible.