Groping in the Dark

Groping around in the dark, that’s where I am today.  The lights are on, but there is not much to see.  At least that’s the way it feels when I’m debugging this nasty piece of spaghetti.  There’s no one to blame but myself.  I rolled this lump of pasta. 


The debugger is nice, but it’s difficult to get the big picture when my data structures are huge and nested to the nth degree.  I can click, click, click at the tree window and follow it to my heart’s content, but the bits I need to compare and track are at the deep outer edges.  So I resort to all sorts of ‘backdoor’ debugging; writing giant messages out to the console, and then debugging changes from looking at the code to staring at my own obscure hieroglyphics.  I’m sure you do it too. 


So I was thinking that we (meaning you all out there) could compile some sort of compendium of secret tricks for debugging apps that are unwieldy just due to the large amounts of data and or complexity in their states. 


I’ll start.


1)      Writing tons of obscure messages to the console window.

2)      Abandoning all hope, avoiding the problem, blogging instead, and hoping my brain works on the problem in the background.

3)      Staring at the code outside the debugger until I magically see the problem.  (This actually works much of the time.)




Comments (11)

  1. LOL… Matt, I feel your pain 🙂 Debugging multi-threaded debuggers is probably one of the hardest things I’ve had to do.

    I generally revert to writing to the Console or, if it’s a threading thing, I use MessageBoxes.

    Either way I lay my debugging hints down as a sort of breadcrumb-trail through the code path so that I can see what is being hit and when.

  2. jaybaz [MS] says:

    4. Add unit tests to verify my assumptions / test my hypotheses. Debugging this way is more repeatable than using a real debugger.

    5. Refactor the code in question until it makes sense and the bugs are easy to see.

  3. jaybaz [MS] says:

    4. Add unit tests to verify my assumptions / test my hypotheses. Debugging this way is more repeatable than using a real debugger.

    5. Refactor the code in question until it makes sense and the bugs are easy to see.

  4. Mike Andrews says:

    One of the best papers written on the subject of debugging (and how people go about it) is Marc Eisenstadt’s "’My hairiest bug’ war stories" (or "tales of debugging from the front lines" depending on where you find it) []

    I myself looked into this and did a small survey of tools people used for debugging, and what features of a debugger they used the most. If anyone is intersted, feel free to have a look at [].

  5. Matt says:

    Got unit tests, that’s why I know I have bugs. The code has been refactored, that’s what I’ve been doing to it. I changed a whole bunch of the architecture. Now it doesn’t work in some instances, and deducing what it wrong is the hard part. The code is relatively simple, but the data is huge so watching it happen at any small granularity is burdensome. Trying to deduce what happened at a large granularity is difficult as well.

  6. My first step is usually to comment out all the logic I can get away with, see if I’m getting expected results. Then start adding bits in, one by one, until something cracks. Also a good way to get my mind around code I wrote and don’t remember what it does. 🙂

  7. I’m tend to agree with Avner, but here’s my personal take. Though, logic would dictate that some sort of "binary chop" approach of dividing the functionality would be the quickest, time and time again I’ve found the problem is at one extreme i.e. bad input initially, or a logic error in the deepest darkest bit of the code. I therefore tend to sanity check the inputs (there’s normally something that conceptually counts as input) first, as that’s generally easiest, and if they seem fine head to the other extreme and doing some logging/assertion in that deeply nested loop that I wrote one Friday afternoon and promised I’d come back the next Monday. Which reminds me of another approach: look for dodgy sounding comments, esp. HACK, TODO et al.

  8. Matt,

    i’m normally just trying to come up with possible explanations – next, trying to verify them. this is very much trial on error, but if the data set is just to big to step through all cases: well, inthatcase its too damn big.

    btw: for me, the best way to come up with explanations is talking to other people, trying to explain whats wrong.


    thomas woelfer

  9. Nick says:

    You talked about what a pain the debugger was because the members you were looking at were at the outer edges of your data structures… which got me thinking about one of the annoying things with the current debugger…

    When you do expand a tree in the watch window and then step out of that objects scope… and then possibly come back into its scope, wouldn’t it be nice if the watch window remembered the state of the tree and put it back the way it was instead of defaulting to always collapsed?

  10. Matt says:

    I solved it, yesterday, before I went home. I did it by staring at the output for an hour and then making a guess as to what could possibly have gone wrong. I was lucky.

  11. Scott Allen says:

    VS.NET 2005 visualizers will be *great* for debugging, but of course not the solution for everything.

    One thing I’ve done in the past to debug complicated data structures was to take snapshots to a file, then use a diff tool to see what is changing. Then I could also compare what happened when the software was functioning correctly versus what happened when things went screwy. It helped in that scenario tremendously.

Skip to main content