Computing Reviews
Today's Issue Hot Topics Search Browse Recommended My Account Log In
Review Help
Search
My hairiest bug war stories
Eisenstadt M. (ed) Communications of the ACM40 (4):30-37,1997.Type:Article
Date Reviewed: Nov 1 1997

Having at one time plied the ACM Lectureship Series circuit with a talk entitled “Entomological Tales,” I looked forward to reading this paper. I was disappointed to discover that the title was only vaguely related to the content--there are only a few stories, and none of them are the author’s own experiences. But even if the paper is not as entertaining as the title would suggest, it is both interesting and useful.

The author answers three questions: What properties of bugs make them hard to find? How do programmers actually track down difficult bugs? And what, typically, are the root causes of those bugs? To answer these questions, Eisenstadt posted a request for debugging anecdotes to several bulletin boards and Usenet newsgroups.

The most frequent source of difficulty reported was a chasm between cause and effect: the symptom is often far removed in space or time from the cause. Other common problems are “Heisenbugs” (named for the Heisenberg uncertainty principle), in which debugging tools make a bug disappear; misreadings of that which is plainly in view; and faulty assumptions about the code.

The bug-catching technique used most by Eisenstadt’s respondents was the gathering of data through print statements, breakpoints, dumping, profiling, and similar methods. Other common techniques used were code inspection combined with hand simulation, having someone else recognize a bug cliche, and controlled experiments.

The most common root causes of bugs were memory-related: having data overwritten or used up. Some other common causes were defects in support software, faulty design logic, and wrong initializations or data types.

Based on the joint occurrences of sources of difficulty, debugging techniques, and root causes, Eisenstadt concludes that a particularly useful debugging tool would employ data-gathering methods to track down memory errors with a large cause/effect chasm. More generally, he suggests that “war stories” are a fruitful source of information about how debugging needs can be addressed systematically.

Reviewer:  P. Abrahams Review #: CR120844 (9711-0918)
Bookmark and Share
 
Testing And Debugging (D.2.5 )
 
 
General (D.2.0 )
 
Would you recommend this review?
yes
no
Other reviews under "Testing And Debugging": Date
Software defect removal
Dunn R., McGraw-Hill, Inc., New York, NY, 1984. Type: Book (9789780070183131)
Mar 1 1985
On the optimum checkpoint selection problem
Toueg S., Babaoglu O. SIAM Journal on Computing 13(3): 630-649, 1984. Type: Article
Mar 1 1985
Software testing management
Royer T., Prentice-Hall, Inc., Upper Saddle River, NJ, 1993. Type: Book (9780135329870)
Mar 1 1994
more...

E-Mail This Printer-Friendly
Send Your Comments
Contact Us
Reproduction in whole or in part without permission is prohibited.   Copyright 1999-2024 ThinkLoud®
Terms of Use
| Privacy Policy