A Guilty Secret

Thu Mar 22, 2012

Ok.  I admit it.  I sometimes use text based debugging.  It’s ugly and when there is a better way, I jump to the alternative, but sometimes "printf"s hidden behind a preprocessor define are the fast tool to figuring out what is going on. 

Generally I prefer using trace breakpoints, visual breakpoints (described in an early blog), or assertions to test hypotheses about what went wrong.  Other times, a fancy tool ( memory access checker, profiler, thread safety checker) is just the thing.  Basically, I look at the bug description, reproduce the issue, and then visualize it.  Given reasonable knowledge about what the code is trying to do, a picture usually gets me a short list of what could be wrong.  Then I try to eliminate possibilities.

But sometimes, the test cases to reproduce problems are too big for visual breakpoints to tell the whole story.  In these cases, "some breadcrumbs" from the call stack is just the thing I need.  If the edge facets went wrong, I log all the places where the faceter made an AF_POINT.  If the quad tree didn’t work, log each step of its creation to see where we made an unnecessary split or failed to make a necessary one.

A good text editor and "diff" like program gives you some leverage that you wouldn’t otherwise get.  Together with pictures of the problem, this can be just the thing.

So: do you have any guilty secrets related to debugging?

Subscribe to the D2D Blog

No Comments Yet

Let us know what you think