Beautiful Code [308]
It turned out, though, that at this time, I was pretty fed up with running debuggers, debugging our own debugger, and in particular debugging because of third-party changes.
Figure 28-1. The ddd debugger in action
So, I sat back and wondered: is there a way to solve this problem without actually launching the debugger? Or: can I debug something without debugging?
Since the problem was caused by a change to the gdb source code, I could simply look into the gdb code—or, more precisely, at the differences between the two releases. The code difference, so I thought, would point me directly to the failure-inducing change. All I needed to do was to run the two code bases through diff, a tool for detecting text differences. And this I did.
The diff results surprised me. The log had a length of 178,200 lines, which was enormous—especially considering that the total gdb source code contained roughly 600,000 lines of code. In no less than 8,721 locations, developers had inserted, deleted, or changed the source code. This was quite a lot for a "minor" release and, of course, far more than I could handle. Even if it took me just 10 seconds to check a single location, I would still spend 24 hours searching for the troublesome change. I sighed, invoked the debugger, and braced myself for yet another boring debugging session. Still, I thought, there must be a better way to do this—a more "beautiful" way.
Beautiful Debugging > A Systematic Process
28.2. A Systematic Process
When programmers debug a program, they search for a failure cause, which could lie in the code, the input, or the environment. This cause must be found and eliminated. Once the cause is eliminated, the program works. (Should the program still fail once the cause is eliminated, we may need to revise our beliefs about the cause.)
The general process for finding causes is called the scientific method. Applied to program failures, it works as follows:
Observe a program failure.
Invent a hypothesis for the failure cause that is consistent with the observations.
Use the hypothesis to make predictions.
Put your predictions to the test by experiments and further observations:
If experiment and observation satisfy the prediction, refine the hypothesis.
If not, find an alternate hypothesis.
Repeat steps 3 and 4 until the hypothesis can no longer be refined.
Eventually, the hypothesis thus becomes a theory. This means that you have a conceptual framework that explains (and predicts) some aspect of the universe. Your failing program may be a very small aspect of the universe, but still, the resulting theory should neatly predict where you should fix your program.
To obtain such a theory, programmers apply the scientific method as they walk back through the cause-effect-chain that led to the failure. They:
Observe a failure ("The output is wrong").
Come up with a hypothesis about the failure cause ("The problem may be that y has a wrong value").
Make a prediction ("If y is wrong, its value may come from f() in line 632").
Put their prediction to the test ("Indeed, y has a wrong value in line 632").
Draw appropriate conclusions ("This means that f() returns a wrong value. Now where does this come from?").
Among all methods, hints, and tricks, the consistent and disciplined use of the scientific method is the key to becoming a debugging master. This means three things:
Be explicit
Formulate your hypothesis explicitly. Write it down or explain your problem to other people. Keep a written track of your hypotheses and observations so you can interrupt your work and start the next morning with a fresh mind.
Be systematic
Make sure you know what you're doing. Don't investigate (or change) something at random without having a clear hypothesis and a resulting prediction. Be sure