Capture a live failing process and replay the process execution history to get instant visibility into what your process just did and why.
Ideal to quickly fix race conditions, segmentation faults, stackoverflow errors, double free or memory corruption in C/C++ programs running on Linux x86.
▪️ Fix bugs faster by reducing debugging down to just one cycle
▪️ Get to the root cause of bugs with 100% certainty
▪️ Understand codebases you didn’t write
Time Travel Debugging greatly improves team productivity in development. It is also ideal to debug test failures.
▪️ Travel forward and backward in time to inspect program state
▪️ Replay program execution to understand exactly what went wrong and why
▪️ Just see what happened rather than trying to figure it out
▪️ Reverse debugging
▪️ Single step forward or backward
▪️ Run forward or backward
▪️ Hit breakpoints, conditional breakpoints & watchpoints - running forward or backward
▪️ Jump to a bookmark in your program’s execution history
▪️ Jump to specific a moment in time in your program’s execution
▪️ Full inspection of global and local variable values
▪️ Full compatibility with GDB commands
▪️ Command-line debugging or integrate in your IDE
Play with the arrows above the animation on your right to get a mini taster of how UDB works.
Multithreaded and multi-process application architectures help improve performance; but they also increase the risk of challenging concurrency defects occurring, such as race conditions, shared memory corruption, or deadlocks.
UDB is ideal for rapidly debugging concurrency defects.
Read tutorial on how to debug C/C++ race conditions with UDB
UDB is also used to rapidly identify the root cause of programming errors related to memory management such as:
▪️ Segmentation faults (segfault) due to memory access violation (stackoverflow, write/read violation etc)
▪️ Double free
▪️ Memory corruption
▪️ Stack corruption i.e. buffer overrun
These can be hard to debug since the root cause may no longer be in scope. With UDB, you can just see what went wrong by travelling back in your program’s execution history.
Working on complex unfamiliar code?
Observe program behavior by navigating forward and backward in the program’s execution history.
Watch variable and memory changes as you navigate - forward and in reverse.
When dealing with unfamiliar code, there is a huge productivity benefit in being able to go backwards and forwards over the same section of code until you fully understand what it does.
The Undo debugger has helped us efficiently diagnose numerous challenging issues that would have taken much more time to resolve with GDB or other debuggers that are forward-looking with little or no reversibility.
I used UDB to examine registers to find the address of an object. Without UDB, it would have taken me twice as long to debug the problem. I would have ended up running the code over and over with full debug compile to catch the problem. With UDB, I can just back up to the root cause.
UDB runs on most modern Linux distributions and supports both 32 and 64-bit x86 programs. For more details, see the full list of system requirements.
Just UDB Binaries.
No, only user space.
UDB is currently used on some of the world’s most complex software, including heavily multithreaded applications and those using shared memory.
Check out the UDB Quick Reference guide for the full command set available.