Skip to content

GitLab

OpenWalnut Core
OpenWalnut Core

debuggingprofiling

Last edited by Alexander Wiebel
Page history

Debugging and Profiling

Tools

Debugger and frontends

  • kdbg - We recommend to use kdbg on Linux. It is a quite fance front-end for gdb which has not much KDE dependencies, if you concern.
  • gdb - You can also use the console based gdb directly.
  • ddd - Where kdbg is not available you might want to resort to ddd as gdb front-end
  • clewn - A gdb front-end for the VIM text editor.
  • Eclipse CDT - A complete IDE including a nice front-end for gdb.

CMake prerequisites

We support debugging with the script bin/openwalnut-kdbg (you need kdbg for that). This is only generated when the CMake build type was set to Debug or RelWithDebInfo! We recommend you to make a separate build directory for this, e.g. OpenWalnut/build/debug, so you can easily switch between release and debug builds, and do not have to recompile very much unless minor changes.

Profiling time performance with callgrind (Linux only)

We use the Valgrind tool suite for this.

valgrind --tool=callgrind -v --dump-instr=yes --trace-jump=yes bin/openwalnut

Generates a file like callgrind.out.10120 which can be loaded with kcachegrind for graphical analysis.

Profiling memory usage with massif (Linux only)

We use the Valgrind tool suite for this

For installing prerequisites see http://josh.gourneau.com/blog/2010/07/29/massif-visualizer-ubuntu-install-notes/ then checkout and compile these tools:

git clone  git://anongit.kde.org/kgraphviewer kgraphviewer
git clone  git://git.kde.org/massif-visualizer massif-vis

Finally you can start profiling

valgrind --tool=massif --threshold=0.1 --time-unit=ms --detailed-freq=1 bin/openwalnut
massif-visualizer massif.out.15515

Further documentation can be found here: http://valgrind.org/docs/manual/ms-manual.html

Profiling frames per second

Just start OpenWalnut, ensure you have a non-white background for the main view (Camera > Background Colors > main ), put the focus onto the GL-Widget (main view) and press 's'. You should now see a frame rate in the upper left. By pressing 's' again you will cycle through other OpenSceneGraph related status infos. You might also want to have a look on the V-Sync option of your graphic driver, see our FAQ for more information.

Threads

  • Try using names for threads
    • A thread/process can be named on Linux does by using the following command prctl(PR_SET_NAME,"threadname",0,0,0); which needs the following include #include <sys/prctl.h>. The given names can be seen in using top and ps commands in linux (see below). Be aware that this command is Linux specific.
  • kdbg
    • In the "View" menu you can activate a window showing all currently active threads.
    • You can navigate in this window using the arrow keys to show the stack corresponding to each thread in the main window.
  • Linux
    • top - this command shows all running processes. If it is called with -H it shows all threads separately with their names (for naming threads see above).
    • ps - gives you a snapshot of the current processes. If it is called with -L it shows all threads separately with their names (for naming threads see above).

cout-debugging

Also known as printf-debugging. This is the kind of debugging where you put lines that print to standard out in your code in order to find out where the execution is at some time.

  • std::cout << "DEBUG " << __FILE__ << " " << __LINE__ << std::endl;, prints the word "DEBUG", the current file and line number to the standard out.
  • debugLog() << "message"; is available in each module to and serves a similar purpose, or if not in a module: wlog::debug( "WFooBar" ) << ...;

You should consider that this kind of debugging can be annoying and error-prune as multiple threads can write messages in a nearly arbitrary order. But if such messages are added regularly during development, it can uncover problems quite fast, even before they show their ugly face in a crash (especially of-by-one-errors).

See also