Debugger: Odds and Ends

Blog post by anevilyak on Sun, 2013-06-16 17:29
Some time has passed since my last post on the subject, and I keep finding time to work on it, so I thought another update on Debugger progress might be of interest. Most of the features added since my previous post are fairly minor, but should hopefully be interesting/useful nonetheless.


In C++ and various other object-oriented languages, one possibility for propagating/handling errors is by throwing exceptions. As such, being able to stop the running program when one is thrown can be helpful for finding and analyzing problems. Precisely that feature has recently been added to our Debugger, and can be enabled via the "Configure exceptions" button that can now be found on the Breakpoints tab. Once suitably set up, your program will stop when it throws an exception, as seen below:

Currently the feature is quite minimal, as it doesn't yet allow e.g. discriminating between types of exceptions thrown, but that will be improved with time.

Flow control options

Another recently added set of features relate to program flow control. The source view now has a context menu that provides these options. The first: "Run to cursor", allows one to right click a given line, and ask the debugger to continue execution until that specific line of source is hit, without specifying a permanent breakpoint for it. The second is somewhat more specialized: suppose one steps over a line that executes a function call, but the return value winds up being something unexpected. Naturally one would want to know what happened. However, under normal circumstances, the only way to do so would be to restart the program and step into the function the next time. Depending on how that point was reached, getting back to the problem state could potentially be quite time consuming, or even non-reproducible. Instead, one can now pick said line and choose "Set next statement" to reset the instruction pointer there, and subsequently step into the function to see what happens immediately. There are some caveats to this though, as this will only really work in a reliable/useful way if the actions taken by said function don't impact the result of running it a second time. For the circumstances where it's applicable though, it can be quite a time saver.

Image/Functions view improvements

The Functions list in the Images tab has seen a number of suggested changes and improvements in order to make finding functions of interest easier. The first of these is organizational: previously, the list was flat with a top level entry per file, and all of that file's functions underneath. This would rapidly get a bit unwieldy in projects with large numbers of files. As such, this has now been reworked to organize the files based on the actual relative path structure they were built from, as seen below:

However, in some cases, even this isn't enough, since a single file may potentially contain a large number of functions, or a single folder may even contain a large number of files. In such a case, being able to filter the list to narrow down what one is looking for can be quite useful. That can now also be done:

The filter can match on both file paths and function names, and will highlight the matching portion accordingly. Note that shell-style wildcards are likewise supported.


Along with the above, various other minor features have been added: in addition to its flow control duties, the aforementioned context menu in the source view allows one to request opening the current source file in the default editor. Also, the Teams window that's shown on startup by default now sports the ability to start a new team, which was previously only possible via the command line.

Another hopefully helpful addition can be found in the case where a team exits unexpectedly. The dialog that's shown to inform the user of the team's demise now offers the options to either restart the team, quit, or simply do nothing. The latter allows one to set additional breakpoints before eventually restarting the team, so as to hopefully trap the cause of the abrupt exit in question. As per usual, various bugs have also been fixed, and some performance improvements have also recently been made, in particular in the case when stepping between functions in different executable images.

I hope those who regularly use the debugger find these additions helpful, and also want to extend my thanks to all those who offered feedback and suggestions, as quite a number of the improvements in this article were a direct result thereof. Until next time, happy debugging!


Re: Debugger: Odds and Ends

Great job!
One dumb question: is it normal that two lines are highlighted with the same color in the exception screenshot? I suppose one is the last step and the other the exception breakpoint, but it sounds confusing :)

Re: Debugger: Odds and Ends

That's a consequence of the fact that we aren't actually looking at the topmost frame of the call stack. When an exception is thrown, the place where the debugger actually stops is the first function in the C++ runtime that's used to initiate the throw (__cxa_allocate_exception in the case of gcc4, __throw for gcc2). As such, the latter is where the instruction pointer currently is, but since that would simply have been disassembly, it wouldn't have been so interesting to show for a screenshot. The color you see is what's used to highlight all the previous calls in the stack, as is the outlined instruction pointer arrow, and in my particular test case here those happened to be slightly close together. Apologies for the confusion.

Re: Debugger: Odds and Ends

First of all, thanks for the nice write-up. And for continuing to improve Debugger, of course. Keep up the good work!

Regarding the line highlight colors, that's something that has confused me a few times as well. One can see which is the line corresponding to the selected frame by the little arrow left to the line, but I think it would be much nicer, if the highlight color for the non-selected frames would be paler. I don't mind the highlighting in principle, but I think in almost all cases one is primarily interested in the selected frame, so it shouldn't be distracting.

Re: Debugger: Odds and Ends

Will look into that. Perhaps progressively lightening the color the further down the stack one gets would help too? Another possibility that comes to mind is adding a tooltip for the marker lines indicating which frame they correspond to.

Re: Debugger: Odds and Ends

Does this alternative address the ambiguity issue for you and korli?

Re: Debugger: Odds and Ends

Definitely for me, thanks!

Re: Debugger: Odds and Ends

Thanks, looks much better. I'd probably lighten the color even more. I don't think progressively lighening the color would be particularly helpful. Adding the index of the corresponding frame(s) with a small font somewhere on/near the line might be nice, though low priority. The tool tips would be a nice touch, but also low priority.

Re: Debugger: Odds and Ends

Perhaps simply having the non-selected frames show up in a light gray like this then?

Re: Debugger: Odds and Ends

Yep, nice.

Re: Debugger: Odds and Ends

Keep up the awesome work! I need to get stuck back into some Haiku development and knowing this functionality is available is a massive plus. I don't think that the importance of a good debugger can be over stated, it's going to be crucial for everybody developing on the platform.