REFERENCE GUIDE

GDB workflows for crashes, memory, and runtime bases

A debugger session should produce a concrete observation: the faulting instruction, the corrupted value, a runtime base, or a state transition.

Also known as: crash debugging · runtime mappings

gdb-workflowtooling

Mechanism

A debugger session should produce a concrete observation: the faulting instruction, the corrupted value, a runtime base, or a state transition. Save a minimal command sequence that recreates the observation. Separate image-relative offsets from process-specific addresses so ASLR does not silently invalidate the result.

Practical method

Run a reproducer, collect registers and backtrace, then inspect the referenced memory. Identify loaded mappings and disassemble around the program counter. Set a breakpoint before the corrupted value is used. Repeat with a control input to isolate the changed state.

run < input.bin
info registers
bt
x/8i $pc
x/32bx $sp
info proc mappings

Interpreting evidence

A backtrace may be corrupted after an overwrite. The instruction and register state still reveal the immediate fault. Record both the loaded base and the relative offset for relevant code.

Pitfalls and limits

Optimization removes variables and reorders operations. Core dumps may omit mappings. Debugger-induced environment changes can affect allocator layout or anti-debugging behavior.

Sources & further reading

  1. GDB manual ↗gdb

Content license: CC-BY-4.0. Source-derived sections retain their cited licenses and redistribution notices. How this reference is compiled →