Beautiful Code [72]
Curious? Read on.
28.1. Debugging a Debugger
My first experience of beauty in debugging was granted by one of my students. In her 1994 Master's thesis, Dorothea Lütkehaus built a visual debugger interface that provided a textbook visualization of data structures. Figure 28-1 shows a screenshot of her tool, called the data display debugger, or ddd for short. As Dorothea demoed her debugger, the audience and myself were amazed: one could grasp complex data within seconds, and explore and manipulate it just by using the mouse.
ddd was a wrapper for the command-line debuggers in use at this time (in particular gdb, the GNU debugger), which were very powerful tools but difficult to use. Since graphical user interfaces for programming tools were still scarce, ddd was a small revolution. In the following months, Dorothea and I did our best to make ddd the most beautiful debugger interface around, and it eventually became part of the GNU ecosystem.
While debugging with ddd is usually more fun than using a command-line tool, it does not necessarily make you a more efficient debugger. For this, the debugging process is far more important than the tool. Incidentally, I learned this through ddd as well. It all started with a ddd bug report I received on July 31, 1998, which started my second experience of beauty in debugging. Here is the bug report:
When using DDD with GDB 4.16, the run command correctly uses any prior command-line arguments, or the value of set args. However, when I switched to GDB 4.17, this no longer worked: If I entered a run command in the console window, the prior command-line options would be lost.
Those gdb developers had done it again—releasing a new gdb version that behaved slightly differently from the earlier version. Because ddd was a frontend, it actually sent commands to gdb, just like a human would do, and parsed the gdb replies to present its information in the user interface. Something in this process had apparently failed.
All I needed to do was grab and install the new gdb version, run ddd as its frontend, and see whether I could reproduce the problem. If I could, I would have to launch another debugger instance to walk through the problem. All in all, this was business as usual.
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.
29. Treating Code As an Essay
Yukihiro