Many real-world programs can be recorded running at better than half-speed. Others will be a bit worse – 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 be recorded.

👉 Check out performance benchmarks

Undo’s customers record applications:

• with dozens of active threads and 100’s of less active threads
• using custom memory allocators, custom thread libraries
• running on machines with 100’s of cores and terabytes of RAM

For example, the SAP HANA Cloud engineering team invests in the most advanced technologies to ensure stable releases. The team uses Undo’s time travel debugging (combined with thread fuzzing) to debug their highly-multithreaded application with around 5 million lines of productive C++ code. No known bug remains unresolved.

👉 Read the SAP HANA interview

To record memory states, the Undo engine relies on the copy-on-write semantics provided by the operating system, so the memory footprint can be kept relatively low (typically 2x that of the process you are recording).

We can also tune Undo’s behavior adaptively to available RAM.

👉 Learn more

Undo comes as on-premise software, so your data lives with you.

A good proportion of our customers use Undo in production to resolve customer issues orders of magnitude faster than with decade-old debugging practices.

👉 Check out customer stories from Synopsys, Siemens EDA, Cadence or Altair

Undo has the technology to record almost any kind of interaction between the process being recorded and the kernel.

Some of Undo’s customers are networking companies, using very specialized hardware and kernels. Some kernel interactions involving custom devices require optimization by Undo to have good reliability and performance.

Yes – with Undo, you can record multiple, communicating processes running as part of a larger service and then debug them all from the comfort of your development machine.

No need to attach a debugger to multiple nodes of your cluster or to pause components whilst the system is in operation.

Watch this video for an example that traces a bug to the originating node – and to the bad source line – within a distributed C program.

No. No kernel changes or settings, no kernel modules. No special compilation steps either. It just works.

Undo’s technology is based on deterministic process recording. Unlike AI analyses, there is no possibility of hallucination: if a recording says the application did something, then it really did and it could happen again in production. No ifs, buts or maybes.

If you’re already using AI to understand the structure of your code, then consider also using Undo to understand the dynamic behavior of your code. By stepping forward and backward through a recording program, you can see how components interact at runtime.

Undo’s software is designed for Linux, running on x86, x86_64 and ARM64 devices.

We don’t support Risc-V, PPC or MIPS. We cannot record on Windows, MacOS, any of the BSDs or any other OS that is not Linux. On Linux we do support a huge variety of kernel versions and distros.

We cannot record code executed by GPUs, but we can record the CPU side of the interaction with a GPU and, sometimes, that’s all you need.