Tutorial Draft - Using a debugger with oF

Hi guys,

I’m working on writing a tutorial/blog post about using debuggers as I feel a lot of people using openFrameworks are not super familiar with this really handy tool and I wanted to share some of my knowledge about this dark art :slight_smile:

I’d love to hear some feedback if you think I should add details or clarify something before posting it in a more definite place.

On the usage of debugger

Using a debugger can be a really useful tool for troubleshooting a software you’re making or understanding somebody’s else code. Unfortunately this “advanced” feature is too often disregarded by non-expert developers, and sometimes people don’t even know such a thing exists. In this article I’ll try to introduce a few notions that can be useful (I won’t be exhaustive on the usage on the debugger this is barely an introduction), and use openFrameworks and Visual Studio as my base example. I’ll try to remain as generic as possible since those notions are equally meaningful with XCode or whatever half decent programming language you might end up using.

First step : building the application in debug mode

If you want to take full advantage of what your debugger may offer, it’s much better to build your application in Debug mode. In the main visual studio view, you have a drop down menu that either says “Release” or “Debug”. Obviously you want to pick up the latter.
When compiling in debug mode, the compiler puts a lot of extra information and avoid certain optimization so that when you run your application, the debuggers knows what’s happening, which line of your program is being executed, and so on. A side effect is that your application wont run as smoothly as in Release mode (and it’s good practice to build the application in Release mode for production environment).

Navigating through your code

Debugger comes with a really useful concept called Breakpoint. In its most basic form, it says to your software “when you reach this line of code, pause and say hi to the debugger”. To set a breakpoint in visual studio, click in the column to the left of your code, a big red dot should appear. You can set a breakpoint before launching your code in debug mode, or even while it’s running (it’s useuful if you want to break in your update loop for instance after certain things have happened).
Once the debuger has reached a breakpoint, visual studio will come back to focus, and from that point you can do a couple of different things :

If you hover your mouse over a variable, it’s going to show what its value is (and if it’s a complex object/structures you can explore what it contains). You can also dynamically modify the value of basic types (float, bool, …) .
Then you can go to the next line of code by Stepping-in, Stepping over or Stepping out. Here’s the different meaning of those :

Stepping-into : if the next line of code is a function call, the debugger will enter the function and show you the first line of code of the function you’re calling (note : if it’s a third party library, you may end up in dissassembly code as the library may or may not come with debug information)

Stepping-over : the debugger will remain in the current function. For instance if you have something like :

void testApp::update()
if (kinect.isFrameNew())
   frame = ...

You may want to step over the isFrameNew() call (as you don’t care to see what it does inside) but you may want to step into the updatePointCloud function as it’s misbehaving and you want to know why).

And finally you can also Step-out : if you’ve been to far in the depth of code, step out will bring you to the end of the current function (it’s the counter-part of step-into)

Useful shortcuts to remember are F10 to step over and F11 to step into.
And finally F9 is used to set a breakpoint (if you don’t want to use your mouse for doing it)

Tracing your code

Now that you know how to navigate in your code, you can use a mix of stepping in and out to see what’s going on in (nearly) real time. This can become really handy if you have in you hands some foreign code (an openframeworks addons, a coworker application, …) and you want to understand what the program does. Instead of just reading the source code, you can dynamically run it step by step and see what it does and when.

Watches and locals

In visual studio you can add watches by right clicking on a variable and choosing the proper option in the contextual menu. What it does is opening a “Watch” window that shows the value of your watched variables, and stay there until you remove them. It’s much better than using printf,cout, ofLog… to see what’s the value of something at a given moment.
You can also add watches manually by typing the variable name in the watch window (it also works with variable within an object for instance if you y have a ofVec2f v, you can watch v.x)
The locals window is roughly the same thing, it shows you the value of all the variable in the current scope of your function.

More advanced features

You should know that you can create more advanced breakpoints. For instance memory breakpoint might be triggered only if you read or write on a certain memory location (ie a certain variable) and conditional breakpoint can be set to be triggered only if certain conditions are met.

In some situation you may have to debug an application that’s running on your production hardware (which is not the one with visual studio installed). Visual studio comes with a remote debugger tool that is really easy to set up. You install the remote debugger on the production hardware, and then use your developer machine to connect to it. It comes with deployment functionalities (so you can directly push your update on the remote machine). It’s good to know that you can build your application in Release mode with debugging symbols : you won’t be able to access memory values, but when your software breaks you’ll know where in the code it broke. And you can do that with all the regular optimization. A usecase for that is when your application randomly crashes after a couple of hours of usage and your logs are not useful enough to know where the crash happened.

And finally for the most hackers of yours, it’s also possible to debug an application that you don’t have the source code of. Unfortunately it means you won’t see anything but dissasembly code… It might be handy to troubleshoot really specific bug at the junction between your software and third parties libraries that you don’t have the source code.

1 Like

This is awsome, this is the only piece of information that i´ve had found when it comes on debugging. I should learn how to use it.

That´s what it is happening to me. Im having a random error wich happens sometimes, but can´t find it