共用方式為

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.)

4) …

 

Matt

Comments

  • Anonymous
    May 12, 2004
    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.
  • Anonymous
    May 12, 2004
  1. 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.
  • Anonymous
    May 12, 2004
  1. 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.
  • Anonymous
    May 12, 2004
    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) [http://lieber.www.media.mit.edu/people/lieber/Lieberary/Softviz/CACM-Debugging/Hairiest.html]

    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 [www.se.fit.edu/people/mike/signpost].
  • Anonymous
    May 12, 2004
    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.
  • Anonymous
    May 12, 2004
    The comment has been removed
  • Anonymous
    May 12, 2004
    The comment has been removed
  • Anonymous
    May 12, 2004
    The comment has been removed
  • Anonymous
    May 12, 2004
    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?
  • Anonymous
    May 12, 2004
    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.
  • Anonymous
    May 16, 2004
    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.