# GDB Debugging Crashes

**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.

```bash
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:

```bash
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.