Debugging

[jack]

A step-by-step guide to debugging.

1. Do some simple checks and see if it was something obvious.
2. Make a list of everywhere the problem could conceivably be.
3. The bug will be somewhere in the difference between that list and reality.

OK, that's an exaggeration, sometimes the bug is where it should be, but sometimes it really is a matter of "what unexamined assumptions have I made, and which is most likely to be wrong?"

Comments

[ptc24]

Surely the results of step 2 depend on whether you're addressing that list to a rubber duck or not?

[simont]

Perhaps a better plan is to get somebody else to make a list of everywhere the problem could be! Because if you overlooked a possible cause of error when writing the code, there's a good chance you'll overlook the same one again in step 2, unless something has happened to change your thinking.

[gareth_rees]

I know you're joking here, but still: trying to deduce the cause of the bug by pure reason should be your absolute last resort when all else fails! You should heed Richard Stallman in Debugging with GDB: "... the way we will find the bug is by running a single example under the debugger with breakpoints, not by pure deduction from a series of examples."

[jack]

Hm. On the one hand, I believe in the principle a lot, and know I don't apply it anywhere nearly enough. If we had been able to step through, we would have seen the problem immediately. On the other hand, the code is all running on a DSP and there is (I think) no existing mechanism for attaching a debugger. We do have a "simulator" (which doesn't actually simulate the hardware, but runs the same code compiled for a PC), but the problem wasn't with the actual code, but the way one of the flags was set and it didn't show up in the simulator.

[cjwatson]

http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/ubuntu/2011-03-14-wubi-bug-693671.html comes to mind as the last time I learned this lesson.

[jack]

Yeek! Yes.

[catyak]

It's more irritating when you're looking for something that seems to have a one-in-four chance of failing on an overnight run and after several nights of test builds to narrow it down, the bug is (a) not where you thought it was and (b) is under a comment you left when putting in a fix for something else that, with hindsight, makes it bleeding obvious why it occasionally glitches.

D

[eudoxiafriday.wordpress.com]

I am at a much, much lower level of programming-fu than you, and the most recent debugging tip I learnt was "see if your code is actually being run" ... which I suppose is somewhere in the category of "see if it was something obvious". Having spent a couple of hours wondering why nothing I tried made a difference ... yeah. Oops. On the bright side, I probably won't do that again! (The file I was working on was needed by someone else, so I copied across what I was working on to another file and worked on that one but forgot to copy the bit that actually *called* the method ...)

[jack]

*hugs* Funnily enough, that was exactly the problem I had, and after ten years of experience, you still keep having that problem (although hopefully more rarely) :)

In fact, it happened twice. The first time, because the flag we used to toggle the code on and off was being used by something else, which made the whole program not work whenever the flag was turned on. And the second time, because the make system was set up so the #defines worked in the simulator but not on the real code. Afterwards, I resolved again to ALWAYS make sure that the code you wrote is happening, however certain you are... :)