~ / development / gdb
developmentA short gdb field guide
A reminder of the few debugger moves that solve most problems: open a crash, look at the stack, print what matters, and make sure the compiler left the symbols you need.
Open a crash
Point the debugger at the program and the core dump together. The program file supplies the symbols, the core supplies the state at the moment of the crash.
gdb /path/to/program /path/to/core
bt full
The backtrace printed by bt full shows the call frames and the local variables in each one.
Make the output readable
When a structure is printed, ask the debugger to lay it out one field per line and to skip the template noise.
set print pretty on
set print elements 0
print someStruct[0]
Look at the right frame
The crash often happens deep in a library. Choose the frame that belongs to your own code before printing variables, and keep the source view open to follow the line that faulted.
frame 3
list
info locals
Symbols are everything
Without debug symbols the backtrace is a list of addresses. Build the program with symbols enabled and optimisation turned off, then reproduce the fault so the new build produces a fresh core dump.
cc -g -O0 -o program source.c
- Do not strip the binary while investigating.
- Install the matching debug symbol package for any system library in the stack.
- If optimised code hides a value, recompile that part without optimisation.
Further reading
The official manual and its reference card cover far more than these notes: the gdb documentation.