Debugging Hydranode

This page provides information on to provide developers information about crashes and/or wierd behaviour in Hydranode, allowing them to quickly resolve problems that otherwise might take long time to fix. Testers should always have JustInTime debugging enabled (on Windows), and always run latest builds in gdb (on Linux/Mac).

Debugging on Microsoft Windows

You need to have Microsoft Visual Studio .NET 2003 installed on the system, and JustInTime debugging enabled from the IDE (enabled by default). When an application crashes, you see a prompt with Ok and Cancel buttons, instead of the usual "Please tell Microsoft about this problem" dialog. Clicking Cancel takes you to the IDE, where you can then copy/paste the contents of Call Stack window as a new support ticket.

Debugging on Linux and Mac OS X

Required tools

  • GNU Debugger (gdb) - provides stack trace, program state viewing and line-by-line code execution
  • Valgrind - advanced memory debugger and profiler (x86-only)

Debugging using GNU Debugger

To run Hydranode in debugger, enter the follwing commads: 

$ gdb ./hydranode
(gdb) run

When Hydranode crashes, gdb prompt returns, and you see a message like program received signal SIGSEGV (segmentation fault). To give developer's information about the crash, do the following and post the resulting output as a new ticket in the support system: 

(gdb) backtrace full
     ... copy the technical data shown here ...
(gdb) quit

Debugging using Valgrind (only Linux/x86, experienced users)

Valgrind provides extended memory-leak analysis, memory read-write access checking, code profiling, and much more. It also runs the application roughly 10-20 times slower than normal, so high-end hardware is a pre-requisite, as well as 512+ MB of physical memory.

All new code should be run through valgrind at least once, old code should be tested regularly to find deep bugs that might otherwise be left undetected.

Example: 

$ valgrind --log-file=valgrind.log --tool=memcheck --num-callers=40 ./hydranode

You can post the resulting valgrind.log file as a new support ticket if you suspect a deeper bug. For full valgrind usage manual, refer to Valgrind homepage.