Recently, a friend of mine asked me to help him debug his ROS node that was segfaulting. After spotting a fairly easy mistake (using a pointer that holds the address of local variable after that variable was gone), I thought I was done. However, the program kept segfaulting, signaling there was at least another error somewhere. A quick glance to the source code did not yield anything, so I needed a debugger!
Debbuging a ROS node is as simple as debugging a C++ application because
- ROS workspaces are built using catkin, a program built on top of CMake
- a node may need special parameters and/or other nodes to run, thus the usual way of the spawn the the debugger might be hard.
Bot issues are simple to address with the adequate knowledge (pass a flag to catkin and within a launch file, use a node’s
In depths, the application must be compiled with debug symbols. This is fairly easy with the following command :
catkin simply forwards extra parameters to
Hence, each packet in the namespace is built with debug symbols!
For spawning the debugger, I’ll assume that you are using launch, but it should work just fine with GDB (even if I haven’t tested).
Within a launch file, a node has a launch
This attribute holds a string that will be prepended to the actual full command.
Also, ©gdb has an
--args argument that let you specify the program to run from the command line.
Hence, I only had to write
<node pkg="the_pkg" type="the_app" name="the_app_name" launch-prefix="cgdb --args" >
and to be able to debug my node with the usual launch command
roslaunch the_pkg file.launch
EDIT: ok this was in the doc…