Discord
C/C++/Rust Docs
Java/Kotlin Docs
Support

Resources

6 Things You Need to Know About Time Travel Debugging

What is time travel debugging?

Time travel debugging (aka reverse debugging) enables developers to record all program activities at runtime (every memory access, every computation, and every call to the operating system), and then rewind and replay to inspect the program state.

This huge amount of data can be described using a powerful metaphor: the ability to travel backward in time (and forward again) to inspect the program state.

Who needs time travel debugging?

Time travel debugging is particularly beneficial for developers working on complex software systems where traditional debugging methods fall short. This includes:

  • Developers dealing with intermittent or hard-to-reproduce bugs: These “flaky” bugs often appear unpredictably, making them extremely difficult to catch with traditional forward-only debuggers. Time travel debugging allows for a complete recording of the program’s execution, capturing the sequence of events leading to the bug, even if it happens only once.
  • Teams working on multi-threaded and multi-process applications: Concurrency introduces non-deterministic behavior that can lead to subtle race conditions and deadlocks. These problems are notoriously difficult to reason about using conventional debugging techniques. Time travel debugging makes it possible to replay execution deterministically and examine how threads and processes interacted at the moment things went wrong. Techniques such as thread fuzzing can be combined with time travel debugging to deliberately vary thread scheduling and increase the likelihood of triggering rare concurrency bugs. Undo’s feedback-directed Thread Fuzzing goes a step further by analyzing existing recordings to identify shared-memory access points, then increasing thread switching around those areas when re-recording to surface failures more quickly.
  • Engineers debugging production issues: When a bug occurs in a live environment, replicating it in a development setup can be challenging. A time travel recording from production can provide all the necessary context to diagnose and fix the issue without needing to recreate the exact production state.
  • Developers improving legacy codebases: Understanding the behavior of unfamiliar or poorly documented code can be greatly accelerated by the ability to step backward through its execution and observe its state changes.
  • Anyone looking to reduce time spent on debugging: By eliminating the need to restart debugging sessions, add extra logging, and recompile repeatedly, and by enabling developers to trace from symptom to root cause in one cycle, time travel debugging can significantly cut down the time spent identifying the root cause of bugs, leading to increased productivity.

How does time travel debugging compare with other debugging methods?

Traditional debuggers allow developers to step forward through a program and observe its behavior as it executes. In addition to stepping line by line, they provide features such as breakpoints, which pause execution at specific locations, and watchpoints, which stop execution when a variable changes value.

This forward-only approach can work well for simple bugs where the failure occurs close to its underlying cause. Developers set breakpoints at suspected locations, run the program until execution pauses, and inspect state to determine what went wrong.

In practice, this often involves making an educated guess about where the bug might originate, restarting the program under the debugger, and stepping forward to see whether the logic diverges from expectations. If the guess is wrong, the process must be repeated.

For large or complex systems, especially those involving concurrency, this trial-and-error workflow can become time-consuming. The problem is even more pronounced for hard-to-reproduce bugs, where the failure may not appear on every run and the root cause may be far removed from the point where the error becomes visible.

With time travel debugging, a developer only has to run their program once in order to capture a complete record of the program’s execution – including any error that appeared during runtime – in a recording.

A recording not only captures the bug itself, but more importantly, the sequence of events that led up to and caused it.

Time travel debuggers are the single most helpful solution for these types of failures as a programmer can replay and walk through the program’s execution backward, as well as forward, in order to home in on a point of interest.

This enables them to find the root cause from two ends of the program instead of one.

How does time travel debugging work?

Developers have adopted different methods for time travel debugging and there is much discussion about how it works (see for example the StackExchange thread How does reverse debugging work?).

Taking Undo as an example, Undo’s time travel debugger called UDB, provides the ability to instruct the process to go to any previous point in the execution history.

It relies on the fact that many operations in a computer are deterministic and uses this to identify all sources of non-determinism that appear in compiled code (for more information, see introduction to reverse debugging).

This allows developers to address the most time-consuming aspects of debugging today’s multilevel, multicomponent, multithreaded, and multi-process applications.

Capturing failures in practice

The Undo Suite includes the LiveRecorder tool that can record any Linux program by launching it on the command line:

$ live-record /usr/bin/example-application

or by attaching to your program while it is already running:

$ live-record --pid <PID>

After the program terminates, the captured execution history is saved out to a recording file.

The LiveRecorder tool can be integrated into test systems and CI to capture defects without supervision of an engineer. The test system can be configured to automatically rerun failing test cases with LiveRecorder enabled, generating recordings of failures. Tests known to fail intermittently (flaky tests) can also be configured to run repeatedly until the defect is captured.

For more complex setups, the LiveRecorder API can be integrated directly into your program to gain precise control of when and how to start and stop recording. A graphical user interface can make it easier for your QA team and support team to create recordings.

How does time travel debugging affect performance?

Many real-world programs can be recorded running at better than half-speed. Others may be slower – in general, expect 1.5x-5x slowdown per thread (YMMV).

Undo’s dynamic just-in-time instrumentation captures only the minimum data required to replay the process – 99% of the program state can be reconstructed on demand, only the non-deterministic inputs need to be recorded.

We’ve provided benchmarks for how our time travel debugging performs. You can see them here: Undo performance benchmarks.

Does time travel debugging work with my tools and environment?

Time travel debugging functionality is typically exposed either through IDE integrations or via a command line interface, similar to traditional debuggers like GDB.

In the case of Undo’s time travel debugger, UDB can be used through a Visual Studio Code extension or directly from the command line using an interface built on top of GDB.

Support depends on the underlying debugger and operating system, but most time travel debuggers are designed to integrate with standard development environments rather than requiring a dedicated or proprietary setup.

Some time travel debuggers for compiled code are based on the GNU debugger, GDB, and therefore support all languages compatible with GDB (e.g. C/C++, Go and Fortran). For other languages, there are a growing number approaches to time travel debugging tools, such as:

Stay informed. Get the latest in your inbox.

Close
Search

Hit enter to search or ESC to close