rr-debugger/rr: Record and Replay Execution on Linux

What rr records that gdb alone cannot

gdb attaches to a live process and moves forward. When the interesting state has already passed, the usual options are restarting the program and re-creating the input, or setting a breakpoint earlier and running again. rr takes a different route: it records one execution of a process tree, threads included, and then replays that recording under gdb. Because the replay is deterministic, reverse execution becomes practical rather than a curiosity. The README describes the combination of reverse execution with standard gdb and x86 features such as hardware data watchpoints as the point of the tool.

The audience is narrow on purpose. This is for people debugging native Linux applications where a failure is hard to reproduce: a race, a rare input, a crash that shows up once in a thousand runs. If your bug reproduces every time under a normal debugger, rr adds a recording step for little gain. If the bug involves a kernel driver, a GPU stack, or anything the recorder cannot capture, rr is the wrong instrument.

How recording and replay actually work

The README does not describe the internal mechanism in detail; it points to the paper Engineering Record And Replay For Deployability as the technical overview. What the repository does establish is the shape of the tool: it records execution of trees of processes and threads, and replay is deterministic enough that gdb can step backwards through it.

The requirements explain why. rr needs Linux kernel 4.7 or later for __WALL support in waitid(), and it needs CPU support for hardware performance counters: Intel Nehalem (2010) or later, certain AMD Zen or later processors, or certain AArch64 microarchitectures such as ARM Neoverse N1 or the Apple Silicon M-series. Running inside a VM is supported when the VM virtualizes hardware performance counters. The README names some VMware and KVM configurations, and some AWS and GCP configurations, as known to work, and states that no Xen configuration is known to work.

That dependency list is the honest summary of the architecture. rr is not a portable interpreter of your program; it depends on specific hardware and kernel behaviour to capture execution faithfully. Where those counters are unavailable or not virtualized, the tool cannot do its job.

Installing rr on Ubuntu and taking a first recording

The README does not carry install steps or command examples. It sends readers to the project site at rr-project.org and to the wiki page Building And Installing, and the repository keeps its build entry point at the top level as CMakeLists.txt and configure. Treat those as the source of truth for your distribution, because the README gives no package names, no version numbers and no build flags.

What the README does state is the shape of the workflow: recording execution, then replaying it under gdb with reverse execution. The exact invocation belongs to the wiki, not to this article, so read Building And Installing before you run anything. The system requirements section is the part you can act on immediately: check that your kernel is at least 4.7 and that your CPU is on the supported list before you spend time on a build.

If you are on a VM, the README adds a second check: the guest must support virtualization of hardware performance counters. Some VMware and KVM configurations and some AWS and GCP configurations are known to work, and no Xen configuration is known to work. Confirm that before installing, because it is not something you can fix after the fact.

Where rr stops being the right tool

The CPU requirement is the first wall. Nehalem is from 2010, so most x86 machines clear it, but older hardware and some virtualized environments do not. The README is explicit that Xen is not known to work in any configuration, which rules out a class of hosting and lab setups outright. If your team standardizes on Xen guests, rr is not a candidate regardless of how well it fits the debugging problem.

The second wall is the kernel. Version 4.7 is the floor, and the README notes that rr 5.6.0 still worked with kernel 3.11 because it required PTRACE_SETSIGMASK. That note is useful for anyone pinned to an old distribution kernel: newer rr releases will not run there, and the workaround is to stay on an older rr, which means forgoing later fixes.

The third wall is scope. rr records and replays native process execution. It is not a profiler, not a sanitizer, and not a substitute for logging in production. The README frames it as a debugging tool, and nothing in the repository description suggests it is meant to run continuously alongside a live service.

rr against gdb's built-in record and replay

gdb has its own record and replay facility, and that is the closest comparison. The difference is in what each design optimizes for. gdb's built-in recording is tied to the debugging session and is generally aimed at short windows of execution; the README positions rr as efficient reverse execution over a recorded process tree, with the recording being a first-class artifact you can replay later.

That distinction matters operationally. With rr, the recording step and the debugging step are separate, so a recording can be captured once and examined repeatedly, on a different schedule, or by a different engineer. The cost is the setup: supported CPU, kernel 4.7 or later, and a VM that virtualizes performance counters if you are not on bare metal. If your debugging sessions are short and your hardware is unusual, gdb's built-in facility avoids the dependency list entirely.

Maintenance, releases and the licence field

The repository is not archived, and the last push was on 2026-09-19, so development activity is current. Releases are infrequent and deliberate: 5.9.0 on 2025-02-13, 5.8.0 on 2024-05-20, and 5.7.0 on 2023-10-03. That cadence means upgrade cost is low for most users, but it also means a fix you are waiting for may sit for months. Plan around the release train rather than expecting continuous drops.

The licence field is NOASSERTION, which is not a licence name. The repository has a LICENSE file at the top level, and that file is what you need to read. Until you have read it, do not assume the terms match any common licence, and do not treat the field as a grant of rights. This is a description of what the repository states, not legal advice.

Editorial conclusion

Adopt rr if you debug native Linux applications on a supported Intel Nehalem or later, AMD Zen or later, or AArch64 machine, and you can accept the kernel 4.7 floor and the wiki-only install path. Do not adopt it if you need Windows or macOS hosts, Xen guests, or you rely on the README alone for setup guidance, because the README points to the wiki rather than carrying the steps. Before committing, verify three things on your own hardware: that the CPU is on the supported list, that the kernel is at least 4.7, and that the planned use is not blocked by the NOASSERTION licence field, which needs a reading of the LICENSE file rather than an assumption.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. rr-debugger/rr on GitHub