Practical C Programming, 3rd Edition

Chapter 15. Debugging and Optimization

Bloody instructions which, being learned, return to plague the inventor.

—Shakespeare, on debugging [Macbeth, Act 1, Scene 7].

Debugging

The hardest part of creating a program is not its design and writing, but its debugging phase. In this phase, you find out how your program really works (instead of how you think it works).

In order to eradicate a bug, you need two things: a way of reproducing it and information from the program that lets you locate and correct the problem.

In some cases, finding the bug is easy. You discover the bug yourself, the test department produces a clear and easy test plan that displays the bug, or else the output always comes out bad.

In some cases, especially with interactive programs, reproducing the bug may be 90% of the problem. This statement is especially true when you deal with bug reports sent in by users in the field. A typical call from a user might be:

User:

That database program you gave me is broken.

Programmer:

What’s wrong?

User:

Sometimes, when I’m doing a sort, it gets things in the wrong order.

Programmer:

What command were you using?

User:

The sort command.

Programmer (patiently):

Tell me exactly what you typed, keystroke by keystroke, to get it to fail.

User:

I don’t remember it exactly. I was doing a lot of sorts.

Programmer:

If I come over can you show me the bug?

User:

Of course.

Two minutes later, the programmer is in the user’s office and utters the fatal words, “Show me.” The user types away and the program stubbornly ...