HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
rr-debugger
rr
C++2014–2025
rr-debugger / rr

rr

Record and Replay Framework

57Distinct people
68Mentions
0Explicit recommenders
10.7KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Record and Replay Framework

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 1:03:20 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year68 dated mentions

Observed mentions: 2014-03-26 12:19:18 UTC to 2025-06-28 03:42:02 UTC.

0369122014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments20142015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 9 mentions; 0 submissions, 9 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 8 mentions; 0 submissions, 8 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 11 mentions; 0 submissions, 11 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 8 mentions; 0 submissions, 8 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 8 mentions; 0 submissions, 8 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 8 mentions; 0 submissions, 8 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC303
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC000
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC202
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC909
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC808
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC11011
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC808
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC808
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC808
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC202
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC514
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC404

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Overview rr is a lightweight tool for recording, replaying and debugging execution of applications (trees of processes and threads). Debugging extends gdb with very efficient reverse-execution, which in combination with standard gdb/x86 features like hardware data watchpoints, makes debugging much more fun. More information about the project, including instructions on how to install, run, and build rr, is at https://rr-project.org. The best technical overview is currently the paper Engineering Record And Replay For Deployability: Extended Technical Report. Or go directly to the installation and building instructions. Please contribute! Make sure to review the pull request checklist before submitting a pull request. If you find rr useful, please add a testimonial. rr development is sponsored by Pernosco and was originated by Mozilla. System requirements Linux kernel >= 4.7 (for support of __WALL in waitid()) rr 5.6.0 worked with kernel 3.11 (requiring PTRACE_SETSIGMASK) rr currently requires either: An Intel CPU with Nehalem (2010) or later microarchitecture. Certain AMD Zen or later processors (see https://github.com/rr-debugger/rr/wiki/Zen) Certain AArch64 microarchitectures (e.g. ARM Neoverse N1 or the Apple Silicon M-series) Running in a VM guest is supported, as long as the VM supports virtualization of hardware performance counters. Some configurations of VMware and KVM are known to work. Some configurations of AWS and GCP VMs are known to work. No configurations of Xen are known to work. AI usage policy When submitting issues or PRs, please clearly indicate how LLMs were used. Issues or PRs which appear LLM-generated but carry no such indications may be closed without comment. When submitting PRs for review, the submitter must be human and take full responsibility for understanding the changes, regardless of how LLMs were used.
Read the full README on GitHub

What Hacker News says

8 sources
"Time travel debugging" seems to be taking off as the term - "reverse debugger" was around for a long time but doesn't seem to have taken root. It has fixed the conversation of "We make a reversible debugger", "Ah so you put the bugs in", though! > rr is amazing but it doesn't work well in cloud environments where it needs you to configure settings in the virtual machine (which you can't). So this limits it to desktop Linux machines. Hopefully we'll see cloud environments find a way to expose more of the hardware performance counter stuff by default. The alternative is to use an instrumentation-based system that doesn't need access to performance counters. That said, as with machine-level virtualisation, it'd be nice to see the CPU vendors provide more explicit hardware support over time to make implementation easier / higher performan
Read the rest
ce than current approaches. > Valuable, but not as valuable as some other options. Plus, using GDB is. Ugh. Looks like there's some support / guidance for using an IDE interface to rr's GDB - https://github.com/rr-debugger/rr/wiki/Using-rr-in-an-IDE There's also Pernosco https://pernos.co/ which is a cloud service (hosted versions possible) from the original developers of rr. It post-processes uploaded rr traces into a database. This post-processing is compute-intensive but happens on their beefy worker machines. Once it's done, they can retrieve program state across time almost instantly - their website is worth checking out for some examples. At Undo (disclaimer: where I work) we've got a VS Code plugin that's being very actively developed https://marketplace.visualstudio.com/items?itemName=Undo.udb to make it easier to expose the time travel stuff in our LiveRecorder product. > Replay is pretty impressive, but front-end issues don't have as much state as other issues and are typically easier to track. It isn't great with long recordings so you can't just "leave it running". Are you referring to replay.io here? (I was not sure whether you were talking about a replay behaviour in Jive - this is the risk of company / product names that are verbs, a problem we also have!) I've not used their stuff but the debug interface they provide looks really intuitive. They support recording Node so I presume they can do some backend stuff too? (Assuming it's in JS). Looks like they want to apply their techniques to other languages eventually.
In Reverse Debugging and Other Stories
rr numbers each 'event' it records, and you can pass an event number to the gdb 'run' command to tell it to start from that event. Recent 'rr' now also supports the -e option to replay meaning 'start the debug session pointing at the last recorded event, whatever that was'. Details in the usage page: https://github.com/rr-debugger/rr/wiki/Usage AIUI you get 'start at an event' basically for free, because 'step backward' is implemented as 'start at the preceding event and then step forward by N', so events are frequent in the trace and the machinery to get to that point without running all the way from the start of the debug session exists anyway. There's some stuff on the website about how this is all implemented, I think.
In What rr does
This is a good point, but I feel like there was a reason that I couldn’t do this. With Wine under rr, the replays were a bit tricky to get working in the first place. I think it is possible i could’ve done this still, but I first needed to find the number of events to skip for that part of the replay. See this issue: https://github.com/rr-debugger/rr/issues/1687 By the time I got to the point where a reverse continue would’ve been most useful, I’d already left rr due to this issue.
In Sorry, Wrong Number: Debugging a Crash Under Wine
Time travel debugging https://en.wikipedia.org/wiki/Time_travel_debugging : > Interactive debuggers include the ability to modify code and step forward based on updated information.[4] Reverse debugging tools allow users to step backwards in time through the steps that resulted in reaching a particular point in the program. Time traveling debuggers provide these features and also allow users to interact with the program, changing the history if desired, and watch how the program responds.[5] https://github.com/rr-debugger/rr : > System requirements: Linux kernel ≥ 3.11 is required (for PTRACE_SETSIGMASK). > rr currently requires either: > An Intel CPU with Nehalem (2010) or later microarchitecture. [OR] Certain AMD Zen or later processors Is there an rr-like reverse time-travel debugging tool for ARM64/aarch64? Are GUIs like Voltron and
Read the rest
Ghidra helpful for gdb and/or rr-like traces?
In Debugging with GDB

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.