Code Focused
Strategies for Debugging Lots of C++ Objects Effectively
When you have code that is called for many objects it's hard to go through all them and just check line by line. How can you more efficiently debug lots of code?
- By Bartlomiej Filipek
- 10/20/2016
Imagine that in your app's code there's a graph of more than a thousand vertices that represents a map. For some reason, several vertices get corrupted in the processing stage. How would you approach such a scenario and fix the problem?
In my previous debugging tips we've covered how to effectively log information, how to set a conditional breakpoint or add additional helper variables. We can combine these techniques and use them all to track ranges of objects.
Here are some tips that might help:
-
Try to understand what's happening with the data. Select one or more objects and go through the code path. What are the key operations performed on those objects? Where might they be changed/updated?
-
Log out relevant variables and look for outlier results. Even if you need to scan a hundred to a thousand objects, it's easier just to look at the log/output then step into each code path for all of the objects. Maybe those anomalies in the results can point to some problematic range of the data.
-
Think about a unique value or condition that might lead you to an interesting place in the code. Then you can set a conditional break and set a condition that catches some range. The smaller the range, the better.
The general map problem that I've mentioned in the introduction can be approached in the following way:
-
Pick two or more vertices and understand the code path in the processing stage. What happens there?
-
We can log out the variables that become corrupted, then log before and after the processing phase. Do we see any anomalies?
-
For map graphs, introduce some additional variables like a neighbor cities/names. Maybe we can also log them.
After investigating the logs we should narrow the number of vertices to analyze. I am sure we can go from hundreds to tens or even less.
Let's take another example: Often I need to debug code that goes through all the characters in a document's text. One "special" character has issues. It would be impossible to debug every character individually. But I know that this special character has a different bounding box size than the other characters.
So I set a conditional breakpoint and look for a 'width' value that might point to my special character:
width > usual_char_width
With that, the result is that I now only have to check two or three elements, so I can quickly investigate the problem.
Again, I've used a "narrowing" approach from a larger set of cases, so I am able to focus on just several problematic examples.
In general, you want to make your available options as narrow as possible so that you have only several (not tens or hundreds) places to debug.
About the Author
Bartlomiej Filipek is a software developer in Poland who specializes in C++, Windows and graphics programming. He worked for a number of companies developing multimedia, document editors, games, graphics drivers and flight planning systems, and has taught game development at local university. Follow Bart's blog at http://www.bfilipek.com and on Twitter @fenbf.