rr
Record and Replay Framework
A Linux debugging tool that records a program's exact execution once and lets you replay it as many times as needed with full gdb support, including the ability to step backwards through time.
rr is a debugging tool for Linux programs that records what a program does while it runs, then lets you replay that exact execution later. This matters because many bugs are difficult to reproduce: they appear only under specific timing conditions or after long periods of running. With rr, you record the program once, capturing its behavior precisely, and then you can replay that recording as many times as you like to investigate what happened.
The replay is not just a log of output. rr integrates with gdb, the standard Linux debugger, and during a replay session you can pause, step through code, inspect variables, and also step backwards through time. This reverse-execution capability is the core feature. If you see a crash or a bad value, you can run the execution in reverse to find the exact moment the problem was introduced, rather than guessing and re-running repeatedly.
rr runs on Linux and requires an Intel CPU from 2010 or later, certain AMD processors, or certain ARM chips such as Apple Silicon. It can run inside a virtual machine if the VM is configured to expose hardware performance counters (VMware and KVM work; Xen does not). It does not currently support Windows or macOS as the host operating system.
The project was originally created by Mozilla and is now sponsored by Pernosco, a company that builds a commercial debugging service on top of rr technology. The README for this repository is brief and directs readers to the project website at rr-project.org and a technical research paper for deeper documentation.
Where it fits
- Record a flaky test that crashes only occasionally, then replay the exact failure under gdb to find the root cause without having to reproduce it again.
- Step backwards through a program's execution in gdb to find the exact line where a variable got corrupted or a bad value was introduced.
- Capture a hard-to-reproduce production crash in a recording and share the file with a teammate so they can investigate it locally using gdb.
- Use rr with Pernosco to get a collaborative debugging session where multiple people can explore the same execution recording together.