Autoproj

Debugging techniques

The following section list some techniques that allow to investigate deeper:

Improve logging and increase the logging level

For Orocos components you can set the Orocos logging level via the enviroment variable ORO_LOGLEVEL to a value from 1 to 6.
Where 6 allows the DEBUG messages to the shown.

export ORO_LOGLEVEL=6

For libraries its is recommended to use the base logging. In order to activate you can use the environment variable BASE_LOG_LEVEL. Unset the variable to deactivate logging. Otherwise you can set the logging level for the base logger the following log levels:
"DEBUG", "INFO", "WARN", "ERROR", "FATAL"

export BASE_LOG_LEVEL="DEBUG"

If you haven't included any logger into your library use the one provided by base. You find the source in
base/types, i.e. if you are using the Rock Macros you will have to link to base-lib (yes, base-lib).
If you are not using Rock Macros but only CMake you have to do the following

C/C++ >> gdb (gnu debugger) and ddd

The following steps allow you to perform post mortem analysis once your C/C++ program fails and generates a core dump.
Change the pattern of the core dump filename since the default is just core

sudo su
echo "core.%e.%p.%h" > /proc/sys/kernel/core_pattern

In order to get a core dump, allow the core dump size to be unlimited, i.e. in the active shell:

ulimit -c unlimited

Next time your program crashes you will get a properly (given your pattern) named core dump. Call gdb with it, i.e.

gdb <name-of-your-executable> <core-dump-file>
bt

Valgrind

You can test your libraries directly with ​valgrind.
Note that there are different tools available for valgrind, e.g. memcheck, cachegrind, callgrind, helgrind or massif, while memcheck is the default one applied.