-
Notifications
You must be signed in to change notification settings - Fork 467
Debugging
This page provides tips on debugging various portions of the bladeRF code base.
If you suspect you've encountered a bug that hasn't been reported yet, it is generally very helpful to include results of some preliminary debugging to an issue tracker item, forum post, or question on IRC. When reporting bugs, developers and community members may ask you to provide additional information, using some of the techniques described here.
In most cases, one will want to ensure debug symbols are enabled while debugging. This can be enabled by setting the CMake CMAKE_BUILD_TYPE variable to Debug:
$ cmake -DCMAKE_BUILD_TYPE=Debug ../
GCC/GDB users will likely want to include as much debug information as possible. Use ENABLE_GDB_EXTENSIONS to compile with -ggdb3:
$ cmake -DCMAKE_BUILD_TYPE=Debug -DENABLE_GDB_EXTENSIONS=Yes ../
When dealing with a crashing application, one generally wants to identify:
- The state of the application at the time the failure occurred, including what the program was currently executing, and the state of relevant variables.
- The origin of any incorrect values, such as when a pointer was assigned a NULL value.
To quote the GDB documentation, A backtrace is a summary of how your program got to where it is. Backtraces in GDB show the current stack frame followed by the calling stack frames.
The below examples shows a snippet from a backtrace of the bladeRF-cli, where an invalid loop bound defect was introduced to result in a segfault:
$ gdb --args bladeRF-cli -p # --args is required to indicate that the arguments following the program name are arguments to that program, not gdb
To do...
To do...