Global Sources
EE Times-India
Stay in touch with EE Times India
 
EE Times-India > Embedded
 
 
Embedded  

Perform systematic program debugging (Part 1)

Posted: 25 Jul 2013     Print Version  Bookmark and Share

Keywords:defect  code  bug  fault  failure 

Your program fails. How can this happen? 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 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.

Defining terms: bugs, faults, or defects?
The word bug suggests something humans can touch and remove—and are probably not responsible for. This is already one reason to avoid the word bug. Another reason is its lack of precision. Applied to programs, a bug can mean:

 • An incorrect program code ["This line is buggy"].
 • An incorrect program state ["This pointer, being null, is a bug"].
 • An incorrect program execution ["The program crashes; this is a bug"].

This ambiguity of the term bug is unfortunate, as it confuses causes with symptoms as in, for example:

The bug in the code caused a bug in the state, which caused a bug in the execution—and when we saw the bug we tracked the bug, and finally found and fixed the bug.

This series of articles uses the following, more precise, terms:

 • Defect: An incorrect program code [a bug in the code].
 • Infection: An incorrect program state [a bug in the state].
 • Failure: An observable incorrect program behaviour [a bug in the behaviour].

The wording of the previous example thus becomes clearer: The defect caused an infection, which caused a failure—and when we saw the failure we tracked the infection, and finally found and fixed the defect.

The industry uses several synonyms of these terms.The IEEE standards define the term fault as defect as defined here. They also define bug as a fault, thus making it a synonym of defect—and debugging thus becomes the activity of removing defects in the software.

The terms error and fault are frequently used as synonyms of infection, but also for mistakes made by the programmer. Failures are also called issues or problems. In this series,we use problem as a general term for a questionable property of the program run. A problem becomes a failure as soon as it is considered incorrect. Some defects cannot be attributed to a specific location in the software, but rather to its overall design or architecture. I call such defects flaws. In general, flaws are bad news, because they suggest major changes involved in fixing the problem.

So much for our family of bugs and related terms. Actually, your choice of one term over another shows two things. First, your wording shows how seriously you take the quality of your work.

As Humphrey [1] points out, the term bug "has an unfortunate connotation of merely being an annoyance; something you could swat away or ignore with minor discomfort." He suggests defect instead, and this book follows his advice. Likewise, the word failure is to be taken more seriously than issue. If you find a flaw, you should be truly alarmed.

Second, your choice shows whether you want to attribute failures to individuals. Where bugs seem to creep into the software as if they had a life of their own, Errors and faults are clearly results of human action. These terms were coined by Edsger W. Dijkstra [2] as pejorative alternatives to bug in order to increase the programmers' sense of responsibility.

After all, who wants to create a fault? However, if a program does not behave as intended this may not be the effect of a human mistake. In fact, even a program that is correct with respect to its specification can still produce surprises. This is why I use the terms defect and infection instead of the guilt-ridden faults and errors.

How defects cause failures, and how can we fix them?
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, it prints them as a sorted list on the standard output [$ is the command-line prompt].

$ ./sample 9 7 8
Output: 7 8 9
$ _

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

$ ./sample 11 14
Output: 0 11
$ _

1 • 2 • 3 Next Page Last Page



Comment on "Perform systematic program debugging..."
Comments:  
*  You can enter [0] more charecters.
*Verify code:
 
 
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

 

Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

 
Back to Top