Why Programs Fail

A Guide to Systematic Debugging

Andreas Zeller

• Publisher: Morgan Kaufmann
• Year: 2009
• eBook ISBN: 9780080923000
• Edition: 2
• Topic: Computer Science
• Subtopic: Programming
• Index: Computer Science

Why Programs Fail: A Guide to Systematic Debugging is proof that debugging has graduated from a black art to a systematic discipline. It demystifies one of the toughest aspects of software programming, showing clearly how to discover what caused software failures, and fix them with minimal muss and fuss. The fully updated second edition includes 100+ pages of new material, including new chapters on Verifying Code, Predicting Erors, and Preventing Errors. Cutting-edge tools such as FindBUGS and AGITAR are explained, techniques from integrated environments like Jazz.net are highlighted, and all-new demos with ESC/Java and Spec#, Eclipse and Mozilla are included. This complete and pragmatic overview of debugging is authored by Andreas Zeller, the talented researcher who developed the GNU Data Display Debugger(DDD), a tool that over 250,000 professionals use to visualize the data structures of programs while they are running. Unlike other books on debugging, Zeller's text is product agnostic, appropriate for all programming languages and skill levels. The book explains best practices ranging from systematically tracking error reports, to observing symptoms, reproducing errors, and correcting defects. It covers a wide range of tools and techniques from hands-on observation to fully automated diagnoses, and also explores the author's innovative techniques for isolating minimal input to reproduce an error and for tracking cause and effect through a program. It even includes instructions on how to create automated debugging tools. The text includes exercises and extensive references for further study, and a companion website with source code for all examples and additional debugging resources is available. - The new edition of this award-winning productivity-booster is for any developer who has ever been frustrated by elusive bugs - Brand new chapters demonstrate cutting-edge debugging techniques and tools, enabling readers to put the latest time-saving developments to work for them - Learn by doing. New exercises and detailed examples focus on emerging tools, languages and environments, including AGITAR, FindBUGS, Python and Eclipse

CHAPTER 1 How Failures Come to Be

Your program fails. How can this be? The answer is that the programmer creates a defect in the code. When the code is executed, the defect causes an infection in the program state, which later becomes visible as a failure. To find the defect, one must reason backward, starting with the failure. This chapter defines the essential concepts when talking about debugging, and hints at the techniques discussed subsequently—hopefully whetting your appetite for the remainder of this book.

1.1 MY PROGRAM DOES NOT WORK!

Oops! Your program fails. Now what? This is a common situation that interrupts our routine and requires immediate attention. Because the program mostly worked until now, we assume that something external has crept into our machine—something that is natural and unavoidable; something we are not responsible for—namely, a bug.

If you are a user, you have probably already learned to live with bugs. You may even think that bugs are unavoidable when it comes to software. As a programmer, though, you know that bugs do not creep out of mother nature into our programs. (See Bug Story 1 for an exception.) Rather, bugs are inherent parts of the programs we produce. At the beginning of any bug story stands a human who produces the program in question.

The following is a small program I once produced. The sample program is a very simple sorting tool. Given a list of numbers as command-line arguments, sample prints them as a sorted list on the standard output ($ is the command-line prompt).

Unfortunately, sample does not always work properly, as demonstrated by the following failure:

BUG STORY 1

The First Bug

We do not know when the first defect in a program was introduced. What we know, though, is when the first actual bug was found. It may have been in search of plant food, or a warm place to lay its eggs, or both. Now it wandered around in this humming, warm machine that constantly clicked and rattled. But suddenly, it got stuck between the metal contacts of a relay—actually, one of 13,000 high-performance relays commissioned for this particular machine. The current killed it instantly—and its remains caused the machine to fail.

This first actual bug was a moth, retrieved by a technician from the Harvard Mark II machine on September 9, 1947. The moth got taped into the logbook, with the comment” 1545 Relay #70 Panel F (moth) in relay. First actual case of bug being found.” The moth thus became the living proof that computer problems could indeed be caused by actual bugs.

Although the sample output is sorted and contains the right number of items, some original arguments are missing and replaced by bogus numbers. Here, 14 is missing and replaced by 0. (Actual bogus numbers and behavior on your system may vary.) From the sample failure, we can deduce that sample has a bug (or, more precisely, a defect). This brings us to the key question of this chapter:

HOW DOES A DEFECT CAUSE A FAILURE, AND HOW CAN WE FIX IT?

1.2 FROM DEFECTS TO FAILURES

In general, a failure such as that in the sample program comes about in the four stages discussed in the following.

1. The programmer creates a defect. A defect is a piece of the code that can cause an infection. Because the defect is part of the code, and because every code is initially written by a programmer, the defect is technically created by the programmer. If the programmer creates a defect, does that mean the programmer was at fault? Not necessarily. Consider the following:

The original requirements did not foresee future changes. Think about the Y2K problem, for instance.

A program behavior may become classified as a” failure” only when the user sees it for the first time...

Table of contents

• Cover image
• Title page
• Table of Contents
• Copyright
• Foreword
• Preface
• ACKNOWLEDGMENTS
• Chapter 1: How Failures Come to Be
• Chapter 2: Tracking Problems
• Chapter 3: Making Programs Fail
• Chapter 4: Reproducing Problems
• Chapter 5: Simplifying Problems
• Chapter 6: Scientific Debugging
• Chapter 7: Deducing Errors
• Chapter 8: Observing Facts
• Chapter 9: Tracking Origins
• Chapter 10: Asserting Expectations
• Chapter 11: Detecting Anomalies
• Chapter 12: Causes and Effects
• Chapter 13: Isolating Failure Causes
• Chapter 14: Isolating Cause–Effect Chains
• Chapter 15: Fixing the Defect
• Chapter 16: Learning from Mistakes
• APPENDIX: Formal Definitions
• GLOSSARY
• BIBLIOGRAPHY
• INDEX