Have you ever used rr though?
https://github.com/rr-debugger/rr
In nimbme – Nim bare-metal environmentrr-debugger
rr
C++2014–2025
rr-debugger / rr
rr
Record and Replay Framework
57Distinct people
68Mentions
0Explicit recommenders
10.7KGitHub stars
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 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM 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.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 9 | 0 | 9 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 11 | 0 | 11 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 4 | 0 | 4 |
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 GitHubWhat Hacker News says
68 sourcesI'm sure that feature is important for whatever works you're doing, but that's a feature I've _never_ desired, and WSL is missing plenty of features that are important for my work.
Hardware performance counters basically do not work in WSL2, which among other issues, makes it extremely difficult to use rr.
https://github.com/rr-debugger/rr/issues/2506#issuecomment-2...
Some people say they got it working, but I and many other users encounter esoteric blockers.
The Dozen driver is never at feature parity with native Linux Vulkan drivers, and that's always going to be the case.
By default, WSL security mitigations cause GCC trampolines to just not work, which partly motivated the opt-in alternative implementations of trampolines last year.
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=28d8c680aaea46...
gWSL is also a terrible X11 server tha
Read the rest
t makes many very basic window management configurations impossible, and while I prefer VcXsrv, it has its own different terrible issues.
I can imagine that WSL2 looks attractive if all you want to do is run command line apps in multiple isolated environments, but it is miserable for anything graphical or interactive.
Yes, io_uring is still not supported due to fundamental issues in the overall rr architecture which my modification does not resolve. My modification only addresses the HW counter requirement of upstream rr and the other core aspects of rr remain the same.
Normal system calls transition to kernel space and return back from kernel space. They will change your program's memory/process state as soon as they complete. This gives rr an easy boundary when it "can do its thing" to record memory/process state changes or insert results (during replay).
When does an io_uring request/response complete ? That's difficult to say. The kernel/userspace when using io_uring communicate with each other by checking a queue head or tail with memory accesses to see if something got added/removed from request/response ring buffer.
Think of io_uring and userspa
Read the rest
ce cooperating via memory. (Yes, sometimes "proper" traditional ring crossing system calls are made but what makes io_uring so fast is communicating via memory and not via system calls most of the time). Anyways all this makes it difficult for rr to intervene on the boundary between kernel and userspace because this boundary is elusive when it comes to io_uring. The memory writes cannot be caught by ptrace ! This explanation is simplified of course.
There are some plans to deal with io_uring by rr maintainers https://github.com/rr-debugger/rr/issues/2613
You probably need the fix from this page: https://github.com/rr-debugger/rr/wiki/Zen
In Show HN: Uscope, a new Linux debugger written from scratchI don't think rr hooks actual kernel writes, but rather just has hard-coded information on each syscall of how to compute what regions of memory it may modify, reading those on recording and writing on replay.
As such, for an asynchronous kernel write you'd want to set up the kernel to never mutate recordee memory, instead having it modify recorder-local memory, which the recorder can then copy over to the real process whenever, and get to record when it happens while at it (see https://github.com/rr-debugger/rr/issues/2613). But such can introduce large delays, thereby changing execution characteristics (if not make things appear to happen in a different order than the kernel would, if done improperly). And you still need the recording system to have accurately implemented the forwarding of whatever edge-case of the asynchronous operatio
Read the rest
n you hit.
And, if done as just that, you'd still hit the problem encountered in the article of it looking like unrelated code changes the memory (whereas with synchronous syscalls you'd at least see the mutation happening on a syscall instruction). So you'd want some extra injected recordee instruction(s) to present separation of recordee actions from asynchronous kernel ones. As a sibling comment notes, rr as-is doesn't handle any asynchronous kernel write cases (though it's certainly not entirely impossible to).
rr took about 9 years to get first class aarch64 support.
https://github.com/rr-debugger/rr/issues/1373
In CRIU, a project to implement checkpoint/restore functionality for LinuxInteresting. Perhaps you can inspect the disassembly of the function in question when using Graal and HotSpot. It is likely related to that.
Another debugging technique we use for heisenbugs is to see if `rr` [1] can reproduce it. If it can then that's great as it allows you to go back in time to debug what may have caused the bug. But `rr` is often not great for concurrency bugs since it emulates a single-core machine. Though debugging a VM is generally a nightmare. What we desperately need is a debugger that can debug both the VM and the language running on top of it. Usually it's one or the other.
> In general I’d argue you haven’t fixed a bug unless you understand why it happened and why your fix worked, which makes this frustrating, since every indication is that the bug exists within proprietary code that is out of my reach.
Were yo
Read the rest
u using Oracle GraalVM? GraalVM community edition is open source, so maybe it's worth checking if it is reproducible in that.
[1]: https://github.com/rr-debugger/rr
RR: Record and Replay Debugger – Reverse Debugger
2 points · Open discussionIt somehow happens that OpenBSD feels like an whole operating system rather than Linux distro built from various components. For example, when pledge(2) and unveil(2) appeared, many user-space programms got patched as soon as possible. You can see simillar process now, after pinsyscall(2) appeared and syscall(2) was removed.
I heard, that there is something simillar in FreeBSD with zstd compression.
For me cons is that you can't run some programms that depends on Linux kernel insides, like rr debugger, which depends on some specific of linux ptrace(2):
https://github.com/rr-debugger/rr?tab=readme-ov-file#system-...
In OpenBSD KDE Plasma DesktopThere it is!
https://github.com/rr-debugger/rr/issues/1373
In Rust, RR, Neovim: A perfect debug combinationThanks so much! I just tried it out and finally got to see time travel debugging working with my own eyes[1]. I'm glad to have it in my toolbox.
[1] Though I had to use sudo a few times, reboot, see some scary warning that it might not work reliably, read https://github.com/rr-debugger/rr/wiki/Will-rr-work-on-my-sy... and https://github.com/rr-debugger/rr/wiki/Zen.
In What a good debugger can do"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.
I think https://github.com/rr-debugger/rr/issues/2034#issuecomment-6... is the right synopsis.
In What rr doesFWIW, rr integrates into gdb, so it should be possible to use anything that integrates with gdb.
https://github.com/rr-debugger/rr/wiki/Using-rr-in-an-IDE
In What rr doesrr 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 doesShowing the 15 most recent of 68 sources. Enable JavaScript to search and browse every indexed mention.