Using a debugger

There are times when your software crushes upon execution. These are the times to use the grim debugger.

Sometimes a program crushes giving an exit code that gives you headaches because this unexpected behaviour's source is not always so clear what it is. Segmentation faults, double freed pointers, memory corruptions and leaks. By using a debugger you can take a closer look to the program's flow near the fault and also examine each variable in use at the point of crash or step-by-step at any point you want. The latter is done by using 'breakpoints'.

• GDB or KDBG: The classical debugging tools.

To use these programs you should:

1. Compile with DEBUG symbols. This could be done by setting the CMAKE_BUILD_TYPE variable in the CMakeLists.txt to Debug. So near the start of the CMakeLists.txt, there should be written:
   set(CMAKE_BUILD_TYPE Debug)
   Alternatively, you should compile using: catkin_make -DCMAKE_BUILD_TYPE=Debug <args>
2. Run GDB/KDBG with the executable's name as an argument. Executables are created after commanding catkin_make in the top level of a catkin workspace and are residing within the devel folder. So, assuming that your catkin workspace is in the home folder you should:
   cd ~/catkin_ws/devel/lib/<your_package's_name>
   In there you will find every executable by its name as you declared it in your CMakeLists.txt with the command: add_executable(<executable's_name> <cpp_files_that_are_compiled>)
   Alternatively, you could invoke GDB from a roslaunch file by appending the option launch-prefix=<wtf_you_want> in the command. See how in the link below:
   http://wiki.ros.org/roslaunch/Tutorials/Roslaunch%20Nodes%20in%20Valgrind%20or%20GDB

How to use these programs:

1. Run the program, check its output, use breakpoints at lines of the source code to stop the flow, run step-by-step, examine the variables declared and their values. For GDB: Use bt to see backtracking function calls to the point of crash. Use frame <number_of_frame> to get in a stack frame (remember that each stack frame responds to a function). Use list to see the source code near the point of the crash in a frame. Use print <variable_name> to print the value of the variable in current frame. Any almost variable that it is legit in C++ can be used in the debugger.
   http://www.yolinux.com/TUTORIALS/GDB-Commands.html
2. Figure out what went wrong.
3. Fix the source code and compile.
4. Return to (1) until bug is fixed. :P