Computing Reviews
Today's Issue Hot Topics Search Browse Recommended My Account Log In
Review Help
Search
Debugging
Stitt M., John Wiley & Sons, Inc., New York, NY, 1992. Type: Book (9780471558316)
Date Reviewed: Sep 1 1993

It is wrong to review a book for what it is not, but it is also wrong to label a book as what it is not. From its title, this book might be trying to tackle debugging at three levels, each of which can be judged separately. As a discussion of debugging for Intel 80x86 chips at the machine and assembly layer, the book is a complete success. As a book on debugging techniques and tools, with examples for Intel 80x86 chips at the machine and assembly layer, it is a partial success. As a general book on debugging, it is a failure.

At the first level, this book is a significant success and a must-read--it is clearly written, thoughtfully organized, and based on real experience and mature reflection. The book comprises five main sections. “Bug-hunting Basics” contains the author’s model of the debugging process: types of bugs and the types of tools to fight them, how to think about debugging, the author’s debugging process model, and necessary steps in fixing a software problem. “Tools” presents resources available to the debugging analyst: hardware features of the Intel 80x86 family of processors (including important interrupts and protected mode operation), Periscope (a commercially available family of hardware-assisted debuggers for Intel chips), a companion toolset, and other tools (not including a list of commercially available tools other than Periscope). “Techniques” is a collection of tactics and strategies for debugging. It includes diagnosis, working with a debugger, “invasive techniques” (techniques where the analyst modifies source code, which are not popular with the author), and “neurosurgery” (what to do when the code was created by a compiler or a linker, of which, again, Stitt is not fond). The appendices include a useful checklist of symptoms versus tactics and tactics versus tools, plus miscellaneous hardware and software samples. The companion toolset is a set of debugging tools on diskette, in source and object form, available at extra cost.

The author’s skills, biases, and preferences are most evident in the later sections. He is most comfortable (indeed, brilliant) with analyzing raw memory and code assembled by hand; the further the code is from this environment, the more uncomfortable he is. This skillset is required by many types of problem exhibited by software on a primitive operating system (MS-DOS) and implemented with primitive languages (such as ASM and C) that lack most elements of error-preventing design; on the other hand, debugging is still required on more mature systems. These biases make the book only a partial success as a general guide to debugging with specific examples. Stitt’s approach tends to guide the analyst into single-stepping through machine code and into analysis of hex dumps, which are literally the last recourse. In a mature system, where operating systems are layered on hardware, network communication is layered on operating systems, application modules are layered on network communication, and application data traffic is layered on application modules, the best (if not only) debugging strategy is to start with the uppermost layer and work down. Most bugs are created in the uppermost layers. (For example, two notorious bugs of the last ten years, the 1985 bug that caused the Bank of New York to lose track of $25 billion worth of securities and the 1990 bug that caused AT&T to lose a day of long-distance telephone calls, were both visible in the source code.) When the bug is in a lower layer, it must be approached by abstracting from the higher layers; the flux of bytes at the machine layer is literally incomprehensible without a grasp of what the system is trying to accomplish.

As a treatise on debugging, the book is a failure. Such a treatise needs perspective on the variety of operating environments; comparative analysis of error types and debugging strategies in different environments; and a grasp of the admittedly meager existing literature on debugging, such as Brown and Sampson [1] and Mosteller [2]. Stitt’s book has no references. Still, it is wrong to review a book for what it is not. This book is an excellent guide to debugging in one environment and an illuminating object lesson for those with more general interests, although, to quote Hu’s review of Mosteller [2] in <CR>, “readers unfamiliar with such an environment should expect to translate the anecdotes and examples back to their own frames of reference.”

Reviewer:  Nicholas Zvegintzov Review #: CR116356
1) Brown, A. R. and Sampson, W. A. Program debugging. Elsevier, New York, 1973. See <CR> 15, 5 (May 1974), Rev. 26,746.
2) Mosteller, W. Systems programmer’s problem solver (2nd ed.). QED, Wellesley, MA, 1989.
Bookmark and Share
 
Testing And Debugging (D.2.5 )
 
 
Corrections (D.2.7 ... )
 
 
Design Tools and Techniques (D.2.2 )
 
 
Reference (A.2 )
 
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