UndoDB is a debugger like no other for compiled programs. As well as the familiar next/step type commands to move the program forwards, UndoDB has commands that step your program backwards. More accurately, UndoDB allows the programmer to view the program's state at any point in the program's execution history.
For user documentation, please see the UndoDB man page.
The file undodb_example.txt contains a log of two UndoDB sessions, showing the effects of the various backwards stepping commands.
See the SUPPORTED SYSTEMS section near the bottom of the online man page for details about which Linux distributions and versions UndoDB supports.
For a history of changes to UndoDB (bug fixes, new features etc), please see the Changelog.
Why time is critical to debugging
To debug a program is to reason backwards from the point of failure to determine the cause of that failure. On the first page of their book, The Practice of Programming, Brian Kernighan and Rob Pike give the following advice to programmers when debugging:
Reason back from the state of the crashed program to determine what could have caused this. Debugging involves backwards reasoning, like solving murder mysteries. Something impossible occurred, and the only solid information is that it really did occur. So we must think backwards from the result to discover the reasons.
With this analogy, a programmer using a bidirectional debugger is like the detective finding detailed CCTV footage of the murder itself, and all pertinent events leading up to it. Traditional debuggers help us to debug code because they let us freeze time, and examine our program's state. Setting a breakpoint means your program will be stopped at a certain time. Single stepping starts your program running only to freeze it immediately afterwards.
UndoDB is different. UndoDB gives you complete control over time during your program's execution. As well as freezing a running program, with UndoDB, you can jump almost instantly to any point in your program's history. You can step backwards over the previous instruction or function call, or back an iteration of a loop. This means you can inspect any part of your program's state at any time in its history.
And there's more. Not only does UndoDB let you go back in time, but when you go forwards again, your program will follow exactly the same path that it did last time. Do you have a bug that bites only one time in a hundred runs? If you can reproduce it under the control of UndoDB you can play that run backwards and forwards as many times as you need to discover exactly what's going wrong.
Everyone who has used a debugger knows the frustration of being able to see the program fail, but not being able to find out where and when it went wrong. For example, step too far in your debugging session, stepping over the offending function? No problem with UndoDB, you can just step backwards into that function. Or perhaps you can see this pointer is NULL that should not be, but how did it become NULL? With UndoDB you can binary chop your program's history to find quickly exactly where it went wrong.
Where traditional debuggers fall down
Most programmers spend most of their time hunting bugs. Whether it's during development itself, or hunting those elusive bugs leading up to or (shock!) after release. Studies show that programmers write an average of 10 lines of code a day. What this means is you write 50 lines of code on Monday morning, and you spend the rest of the week getting them right.
We categorize bugs into three classes:
The trivial. They're diagnosed almost the moment they appear. Most bugs are like this.
The tricky. Here you need tools to help with your investigation. Perhaps a few print statements, or attaching a traditional debugger.
The terrible. There aren't many like this, but because they take such a long time to fix, most programmers spend most of their time hunting these bugs down. Conventional debugging tools rarely help.
The terrible bugs are the ones that bite one time in a thousand runs of your program, and you can never figure out what their cause is. Or where the erroneous state change that is the source of the bug happens a long time before the bug bites and in completely different code. They're the memory overwriting bugs or the reference counting bugs. They make products late to market, and of low quality when they get there. As programmers and managers, they're the bane of our professional lives.
The ability to step backwards with UndoDB is great with the tricky bugs; you can effortlessly go straight to the root of your problem. But it's the terrible bugs where UndoDB really shines. Bugs that would have taken weeks to fix (or perhaps would never be fixed at all) suddenly become trivial. In short, UndoDB turns the tricky and terrible bugs into trivial bugs.
