Skip to the note
zecrazytux.net development  |  note index

~ / development / gdb

development

A short gdb field guide

Development Debugging gdb

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.