Debugger: Odds and Ends

Exceptions

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.

Miscellaneous

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!