Dr. Dobb's | Debugging: The Software Industry's Dirty Secret

Debugging: The Software Industry's Dirty Secret

According to Greg, debugging is the software industry's dirty little secret.

July 02, 2007
URL:http://www.drdobbs.com/tools/debugging-the-software-industrys-dirty-s/200001995

Greg is the cofounder of Undo Software. He can be contacted at www.undo-software.com.

How big a problem are software bugs? In 2002, the U.S. government came up with a startling figure—$60 billion per year in the U.S. alone. But what's amazing is that the study has not been repeated. It's as if we know there is a massive problem here, but we don't seem to care that much.

My beef here is not that bugs are such a problem; these are very difficult problems to solve. My beef is that the issue receives so little attention. Of the 15 million programmers in the world, a tiny proportion is actively addressing this huge issue. For every innovation in preventing and fixing bugs, there are a hundred media players, drawing packages, or even languages and operating systems.

Dealing with the problem of bugs is obviously a question of development process, but technology also has an important role to play. We seem to be getting slightly better at managing process, and the few who are actively working on bug prevention and detection technologies are making demonstrable progress.

Two kinds of bug detection technology hold the most promise—automatic detection of common bugs (attempting to free a block of memory twice, for example), and reversible debugging to help find arbitrary bugs. The two approaches are broadly complementary: Automatic detection is preferable as a means of detecting those common bugs it can find; for all the other bugs, there is reversible debugging.

Notable examples of automatic bug detection include Prevent from Coverity, IBM Rational's Purify, and the open-source Valgrind. Microsoft has invested heavily in automatic checking, particularly for Windows device drivers. These are excellent tools to run over a program and find bugs (often that developers didn't even know existed). Coverity uses static analysis to find what your program might do, whereas Purify and Valgrind dynamically monitor running programs. Dynamic checkers require that you exercise your bug in a test case, whereas static checkers can find problems that have never cropped up. True, they tend to produce some "false positives" but this is usually a price well worth paying.

Complementing the automated tools is a new breed of interactive debuggers that allow better inspection of running programs. Traditional debuggers let you stop the program and peer inside. The program can then be started again, perhaps inching forwards a line at a time. These tools have their uses, but they can't tell you what your program has previously done. Reversible debuggers, however, allow you to rewind a program and inspect its state at any point in the past. The program can jump back or forwards a single instruction or more, letting you home in on the cause of a bug.

Reversible debuggers effectively let you record everything that the program being debugged does—every memory access, every computation, and every call to the operating system. This colossal amount of data is then presented to you via a powerful metaphor—the ability to travel backwards in time (and forwards again) and inspect the program state. RetroVue is an example of such a debugger for Java, Green Hills Software's TimeMachine is a reversible debugger for embedded systems, Undo Software (my company) makes UndoDB—a reversible debugger for native Linux programs—and Microsoft Research has produced Nirvana.

Reversible debuggers fit seamlessly into the traditional debugger model we're used to. While reversible debuggers are bleeding edge today, in a few years, any debugger that lacks this ability will be irrelevant. Automatic checkers are also so useful that it's hard to imagine they won't be the norm in a few years.

Paradoxically, all this good work on debugging makes me more frustrated. These technologies demonstrate that while we'll never "solve" the problem of debugging, there is a lot that can be done. Bugs are arguably the biggest problem in computer science, yet what to do about them receives less attention than other problems that are clearly trivial in comparison. We must do much more to tackle the problem. Recent developments prove that I am not an idealist: We can and must do a lot better than we do now.