Ubuntu Linux for Robotics · Lesson 52 of 96

Debugging ROS 2 nodes with gdb

Debug builds, running a node under gdb, backtraces and core files.

Estimated time · 60–90 min

Learning goals

What you will understand

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

Understand the idea first

The mental model

A C++ node that crashes (segmentation fault) needs a debugger. Build in Debug mode (colcon build --cmake-args -DCMAKE_BUILD_TYPE=Debug), then run the node under gdb through ros2: ros2 run --prefix 'gdb -ex run --args' package node. After the crash type bt to see the call stack.

Install gdb with sudo apt install gdb. Print variables with p, step with n and s, and set breakpoints with b file:line. For crashes on a robot enable core files with ulimit -c unlimited and open them later with gdb node corefile. Valgrind and AddressSanitizer are good second tools.

Guided lesson

Work through these steps

1.
Open a terminal and record the current state before changing anything.
2.
Read the debugging ros 2 nodes with gdb commands and predict what each one does.
3.
Run the commands one at a time and compare each output with your prediction.
4.
Write the commands that worked in a setup note you can repeat later.

Worked example

Read it before you run it

sudo apt install gdb
# Install the debugger.
colcon build --packages-select robot_nodes --cmake-args -DCMAKE_BUILD_TYPE=Debug
# Build with debug information and no optimization.
source install/setup.bash
# Make the debug build visible.
ros2 run --prefix 'gdb -ex run --args' robot_nodes crashy_node
# Run the node under gdb; it stops at the crash.
(gdb) bt
# Print the call stack at the crash.
(gdb) frame 2 then (gdb) p ptr
# Select a frame and inspect a variable.

What the example is doing

1.Lines without sudo only inspect or change files you own; sudo authorizes a system-wide change.
2.Read command output before moving to the next line. Stop if names, versions, disks, or paths differ from the lesson.
3.Comments beginning with # explain safety checks and are not executed by the shell.

Watch it run · Messages between nodes

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

Open a terminal, run the starter line by line (or save it as practice.sh and run bash practice.sh), and replace every TODO with your own command.

# TODO: run the node crashy_node under gdb through ros2 run --prefix

Expected output

The backtrace shows the line that crashed

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

ros2 run --prefix 'gdb -ex run --args' robot_nodes crashy_node

Expected result

How you know it worked

Each command completes without an unexplained error.
Your notes contain the command, the important output, and what it proves.

Practical exercise

Apply the lesson

Write a node with a null-pointer bug, build it in Debug mode, run it under gdb, use bt to find the exact line, fix it and confirm the node runs normally.

Before you continue

You recorded the starting state
Every command and output is understood
The change can be repeated from your notes

If something goes wrong

A command says permission denied.

Check ownership and permissions first. Do not add sudo unless the command changes a documented system location.

A command or package is not found.

Check spelling, Ubuntu version, enabled repositories, and whether the previous installation command succeeded.