Beautiful Code [307]
Beautiful Debugging > Debugging a Debugger
28. Beautiful Debugging
Andreas Zeller
My name is andreas, and i have been debugging." Welcome to Debuggers Anonymous, where you can tell your debugging story and find relief in the stories of others. So you have spent another night away from home? Good thing you've only been in front of the debugger. So you still cannot tell your manager when that showstopper will be fixed? Let's hope for the best! The fellow in the cubicle next to you brags about searching for a bug for 36 consecutive hours? Now that's impressive!
No, there is nothing glamorous about debugging. It is the ugly duckling of our profession, the admission that we are far from perfect, the one activity that is the least predictable or accountable—and a constant impetus to feelings of remorse and guilt: "If only we had done better right from the start, we wouldn't be stuck in this mess." The defect is the crime; debugging is the punishment.
Let us assume, though, that we have done all we can to prevent errors. Yet, from time to time, we will find ourselves in a situation where we need to debug. And as with all other activities, we need to handle debugging in the most professional, maybe even "beautiful" way.
So, can there be any beauty in debugging? I believe there can. In my own life as a programmer, there have been a number of moments when I encountered true beauty in debugging. These moments not only helped me solve a problem at hand, but actually evolved into new approaches to debugging as a whole—approaches that are not only "beautiful" in some way, but actually boost your productivity in debugging. This is because they are systematic—they guarantee to guide you toward the problem solution—and partly even automatic—they do all the work while you pursue other tasks.
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