This page presents comments, ideas, and war stories from you and your fellow debuggers. If you have some comments, ideas, and/or war stories to share, please go to the “Share your stories” page. Stories may be edited — and our apologies to those of you who’ve been waiting around for me to post yours!
“Look at the simple stuff first” from Quentin Lewis.
“A lazy graphics card” from Eddy Carroll.
A fine software demonstration of “Stimulate, don’t simulate” (and “check the plug”) from Frederick Hill.
“Find the feather“, also from Frederick Hill. Here’s an application of the debugging rules to playing an adventure game…
“Dust off those floppies“, from Brian Aust. The real scoop on floppy disks.
“Warming up to the problem“, from Don Borowski. Here’s a case where measuring while it wasn’t failing gave misleading results.
“A few stories on the theme of Check the Plug“, from Nick Coghlan. Read those appnotes and call that vendor.
“Bargain parts“, from Mark. Check the Plug and Get a Fresh View are both nicely illustrated.
Tom Culliton emphasizes that Check the Plug often means checking the user’s configuration, and then adds that you probably want to check the documentation, too — many misconfigurations are caused by bugs in the manual. I agree — this is akin to the oil on the floor problem, where the real source is not enough bolts, which causes vibration, which causes the fitting to shake loose, which causes the oil leak.
Steve Meirowsky has Checked the Plug and found bugs in compilers, linkers, locators, and assemblers. Of course, he has documented and reported every one. I’d like to think these issues are rare, but I once had an IDE whose symbol browser somehow caused the compiler to ignore the last line of the file — sometimes. If every user has just one compiler bug, that’s a lot of bugs.