C++ Intermediate · Lesson 26 of 27

Debugging with gdb

Debug builds, breakpoints, stepping, backtraces and watching variables.

Estimated time · 60–90 min

Learning goals

What you will understand

Explain debugging with gdb in your own words
Use it in a small robotics example
Verify the result instead of assuming it worked

Understand the idea first

The mental model

gdb runs your program under control: you can stop it at a line, look at variables, step one line at a time and read the call stack after a crash. Build with debug information (-g) and without optimization (-O0), or lines and variables will not match what you see.

Useful commands: break (b), run (r), next (n), step (s), print (p), backtrace (bt), continue (c), watch and quit. After a segmentation fault, bt shows the chain of calls that led to it. Under CMake, use -DCMAKE_BUILD_TYPE=Debug.

Guided lesson

Work through these steps

1.
Read the debugging with gdb example and identify what each line owns or changes.
2.
Create a small source file, compile with -std=c++17 and warnings enabled, and run it.
3.
Change one input, predict the result before running, then compare the output.
4.
Record one compiler or runtime error and explain the correction in your own words.

Worked example

Read it before you run it

cmake -S . -B build -DCMAKE_BUILD_TYPE=Debug
# Configure a debug build (adds -g and no optimization).
cmake --build build
# Compile it.
gdb ./build/robot_app
# Start gdb with the program loaded (it does not run yet).
(gdb) break main.cpp:42
# Set a breakpoint on line 42 so the program stops there.
(gdb) run
# Start the program; it stops at the breakpoint.
(gdb) print joint_angle
# Show the current value of a variable.
(gdb) next
# Run one line without entering any function it calls.
(gdb) backtrace
# Show the chain of function calls that reached this point.
(gdb) continue
# Resume until the next breakpoint or the end.

What the example is doing

1.Read declarations from right to left: identify each value's type, name, and initial value.
2.Follow the data through each expression before considering syntax shortcuts.
3.Compile with warnings enabled; a clean build is part of the result, not an optional polish step.

Watch it run · Build and run

See what this code does

The terminal types this lesson's practice solution and runs it. The scene shows the kind of robot behaviour that code drives. It plays by itself and loops.

Practice code

Now type it yourself

Copy the starter into practice.cpp and replace every TODO with your own code. Build and run it: g++ -std=c++17 -Wall -Wextra -Wpedantic practice.cpp -o practice -pthread && ./practice

// Build with: g++ -std=c++17 -g -O0 debug.cpp -o debug   then run: gdb ./debug
#include <iostream>

int first_value(const int* p) {
  // TODO: guard against a null pointer: return -1 instead of dereferencing it (without the guard gdb shows a crash in this line)
  return *p;
}

int main() {
  const int* missing = nullptr;
  std::cout << first_value(missing) << '\n';
  return 0;
}

Expected output

-1

Stuck? Show the full solution (try it yourself first)

// Build with: g++ -std=c++17 -g -O0 debug.cpp -o debug   then run: gdb ./debug
#include <iostream>

int first_value(const int* p) {
  if (p == nullptr) return -1;
  return *p;
}

int main() {
  const int* missing = nullptr;
  std::cout << first_value(missing) << '\n';
  return 0;
}

Expected result

How you know it worked

After adding the shown fragment to the guided exercise with its listed headers and surrounding program, the finished program builds with -Wall -Wextra -Wpedantic.
Changing the stated input produces the result you predicted.

Practical exercise

Apply the lesson

Write a program that dereferences a null pointer in a helper function. Build it with -g, run it under gdb, read the backtrace to find the exact line, then fix the bug and confirm it runs clean.

Before you continue

The program builds with -std=c++17 and no warnings
You can explain the key rule without reading the example
The normal and edge cases both have recorded results

If something goes wrong

The compiler reports that a name or type is unknown.

Start at the first error. Check spelling, required #include lines, and whether the declaration appears before use.

The program runs but the value is wrong.

Print the inputs and intermediate values, then check conversions, units, and collection order.