Reversible debugging is the ability to use a debugger to step an application backward as well as forward. Familiar debugger operations to step the debuggee line-by-line, into, out-of or over functions calls are agumented with reverse counterparts: e.g. step back line-by-line or out of a function to its call-site.
Reversible debugging is a game-changing technology for software development. It is an unpalatable truth that debugging dominates software development. Not only do developers spend the vast majority of their time debugging, but the unpredictability of bugs makes managing software projects a thankless task.
Debugging is like solving a murder mystery: the developer must think backwards to work out what went wrong. A reversible debugger is to a developer as CCTV footage of the murder scene is to a detective. Bugs that would have taken weeks to solve can now be solved in minutes.
Read more about reversible debugging.
UndoDB was the first commercially-available reversible debugger for programs running "native" code. We defined the technology and UndoDB continues to represent the state-of-the-art.
UndoDB's "snapshot-and-replay" technique stores periodic copy-on-write snapshots of the application and only non-deterministic inputs (system calls, thread-switches, shared memory reads, etc). This means a typical CPU-intensive application can run with just 1.7x slow-down compared to native execution, and IO bound applications at close to native speed. Memory requirements are also comparatively very low.
Almost any application can be debugged, including applications that use threads, signals, and/or shared memory. Applications using custom system libraries (e.g. malloc or threading) are supported. We even support applications that directly access hardware (e.g. openGL or Infiniband). UndoDB brings reversible debugging to complex, real-world applications. In short, it's reversible debugging that really works.
Read what's new in UndoDB 3.5
Read more on UndoDB's technical details