Diagnose the root cause of your hardest bugs in hours,
not weeks

THE UNDO SUITE FOR C/C++

The time travel debugger for large-scale enterprise applications

With time travel debugging, developers working on millions of lines of Linux code can now diagnose the root cause of their hardest bugs in hours (not weeks).

Turn weeks of engineering effort into an afternoon debugging session, by getting a full picture of what the program did across subsystems and threads to quickly get an answer to your questions.

  • Deliver well-crafted software
  • Complete code deliverables on time
  • Reduce the pressure that come with debugging customer issues

Ideal for non-trivial bugs e.g. concurrency bugs caused by multithreading, memory corruptions, or flaky tests

What is
Time Travel Debugging?

Record a process. Replay the recording. 

Reconstruct and examine the full state of the program at any point in time. Step back in the execution history to inspect the code flow to see what happened.

Record

Record the bug (on demand or in automated test), capturing the full program execution in a single binary file.

No code or build changes are required thanks to Undo’s just-in-time binary instrumentation.

Replay

Any question you have can be answered from a recording. No more “how did that happen?”.

Recordings are portable, so they can be replayed outside of the original environment and shared with your team.

Resolve

Examine the full state of the program at any point. Go back and forward in time with ease.

Trace from symptom to root cause in one cycle – without having to restart your debug session or recompile.

HOW DOES IT WORK?

UNDO COMES WITH 2 COMPONENTS

LiveRecorder

For generating recordings of your software execution

UDB

For replaying these recordings or for debugging live processes

Available as standalone tool
Image link

WATCH BELOW HOW IT WORKS

100% compatible with GDB, so no need to learn a new tool – just a handful of new commands.
Also available as a VS Code extension or CLion plugin.

WHAT SOFTWARE ENGINEERS SAY

KEY FEATURES

PORTABLE RECORDING FILES
Recordings capture everything your application did. They replay the same, every time, everywhere. They can be replayed outside of the original environment and shared with your team.
TIME TRAVEL
Replay recordings forward and backward to inspect full application state, including the contents of all variables and the heap.
CATCH RACE CONDITIONS
Thread Fuzzing randomizes thread execution to expose concurrency bugs in multithreaded codebases.
Learn more
GDB COMPATIBLE
If you’re already familiar with GDB, it’s just a handful of new commands to unleash the power of time travel.
IDE INTEGRATION
Undo plugs into whatever IDE you prefer (VS Code, CLion, Emacs).
WORKS WITH YOUR EXISTING SYSTEMS
No set up required. No compilation or build changes. No kernel or system configuration.
API CONTROL
Control recording from Undo’s library API to capture what you need, on demand.
FASTER THAN YOU THINK
1.5-5x slowdown whilst capturing on real-world programs, thanks to a just-in-time instrumentation engine that captures only what’s necessary.
Learn more
1ST CLASS SUPPORT
Direct access to Undo engineers and debugging experts to make Undo work smoothly in your environment.

WHY IS UNDO DIFFERENT?

BEFORE UNDO

Lengthy multiple iteration process, reliant on guesswork

Root cause analysis can be frustrating. It takes a disproportionate amount of time. You get stuck in a “add logging-rebuild- re-run-add more logs” loop. Or you step forward in a debugger…until you step too far and you have to restart again.

WITH UNDO

From symptom to root cause in a single debug cycle

Undo makes debugging predictable. You reproduce the issue once and debug the recording (which shows you exactly what happened). The recording will always behave in the same way anytime, anywhere, and for everyone. No more “works on my machine!”.

Capabilities
Undo
Logging, dumps, printf
GDB and IDE debug modes

Shows the whole state of the application - look anything

See how state changed over time - see the story of how things go wrong

Bug capture (including intermittent bugs) is automated

Explore how the code is executed dynamically - every line of code in every thread, every variable, every I/O

Go back to something that happened last week/month

Allows collaboration on the same issue

See what the software really did (not what it was expected to do)

INTEGRATIONS

Want to automate the generation of recording and store them in your CI or bug tracker?

No problem. You can integrate Undo with all popular CI and Test Automation tools, including Jenkins, Maven, Circle CI, or TeamCity.

The core technology is language independent and compatible with most mainstream Linux distributions.

Image link
Image link

Step Into A
Time Machine

  • See what your software really did
  • Solve hard bugs – fast
  • Understand unfamiliar codebases
START YOUR FREE TRIAL

No extra set up steps required.
Get started in 2 minutes.

FAQS

COMMON QUESTIONS

Here are some frequently asked questions and answers you may find helpful. Detailed technical documentation is also available in the

View Docs

Didn’t find the answer to your question? Ask below and we’ll get back to you shortly.

We use binary instrumentation to capture only the bare minimum data required to record execution as efficiently as possible. To keep the overhead low, we don’t translate instructions that don’t require it.

The recording contains all information required to recreate the entire memory state of the recorded process at any machine instruction that was recorded. This includes memory maps, any data read from the file system, network or the kernel generally, and the executable and libraries that were involved with running the application.

Undo works with normal releases without any code or build changes, so you don’t need to modify your code and you need to recompile.

Undo is capable of handling multithreaded applications. Some of our customers record applications with 30-40 active threads and 100s of less active threads. For example it is used on SAP HANA – a heavily multithreaded application that uses custom memory allocators, custom threading libraries and that typically runs on a machine with 100s of cores and terabytes of RAM. Read case study

We don’t usually recommend running all your regressions under recording because the overheads can be significant. Instead, do 2 things:

  1. Configure the test system to re-run failing tests under recording (often up to some upper limit of iterations or for some fixed length of time to catch flakiness)
  2. Create a subset of regression tests that are known to be flaky, and run them repeatedly with recording enabled.

The first is useful for a “pre merge” flow; the latter for if you have a “flaky test problem” (which most engineering teams do to some degree).

Want to see if this could work in your environment?

SPEAK TO AN ENGINEER