Engineering Record And Replay For Deployability: Extended Technical Report · HackerPapers discussions

Engineering Record And Replay For Deployability: Extended Technical Report — mentioned by alehander42

Thu, 06 Mar 2025 17:12:28 GMT

We are currently working on two "backends" where recording works in different ways. For the scripting languages and smart contract/ZK languages, we instrument the interpreters using high level hooking API-s or direct patches, and we produce a trace. For system languages, we directly build on top of RR[1] recordings for now: RR can record multiple processes, and it works in userland. IIRC it doesn't support modifications of shared memory outside of the recording. It's very well documented in their paper: Engineering Record And Replay For Deployability: Extended Technical Report[2]. 1…

Paper and discussion history. A mention is not an endorsement.

Engineering Record And Replay For Deployability: Extended Technical Report — mentioned by roca

Fri, 26 Jul 2024 23:20:21 GMT

The two approaches are completely different. gdb singlesteps the program and, before each instruction, records the state of registers and memory that will be changed by that instruction --- an undo log. Then you can reverse-execute an instruction by restoring the state from the undo log. This is incredibly slow because singlestepping requires a full context switch for each instruction executed. rr, on the other hand, intercepts all system calls and other sources of nondeterminism but regular CPU instructions execute normally with no overhead. The details about rr are here…

Paper and discussion history. A mention is not an endorsement.

Engineering Record And Replay For Deployability: Extended Technical Report — mentioned by khuey

Mon, 22 Jul 2024 03:29:38 GMT

https://arxiv.org/abs/1705.05937

Paper and discussion history. A mention is not an endorsement.

Engineering Record And Replay For Deployability: Extended Technical Report — mentioned by bqmjjx0kac

Sun, 21 Jul 2024 14:32:09 GMT

Yeah, the reason it only works for these coarser race conditions is that RR only has one thread executing at a time. Chaos mode randomizes the durations of time allotted to each thread before it is preempted. This may be out of date. I believe I read it in the Extended Technical Report from 2017: https://arxiv.org/pdf/1705.05937

Paper and discussion history. A mention is not an endorsement.

Engineering Record And Replay For Deployability: Extended Technical Report — mentioned by sfink

Sat, 04 Jun 2022 17:28:37 GMT

No, that has been done but is much slower. It records all communication with the external world. The full answer is well described in https://arxiv.org/pdf/1705.05937.pdf which I'll quote here: > We identify a boundary around state and computation, record all sources of nondeterminism within the boundary and all inputs crossing into the boundary, and reexecute the computation within the boundary by replaying the nondeterminism and inputs. If all inputs and nondeterminism have truly been captured, the state and computation within the boundary during replay will match that during recording. So…

Paper and discussion history. A mention is not an endorsement.

Engineering Record And Replay For Deployability: Extended Technical Report — HN submission

Thu, 18 Jun 2020 16:43:50 GMT

Engineering Record and Replay(rr) for Deployability Extended Technical Report

3 points; 0 discussion replies on HN. Paper and source history. A submission is not an endorsement.

Engineering Record And Replay For Deployability: Extended Technical Report — mentioned by roca

Tue, 05 May 2020 05:04:20 GMT

Some small-ish items: -- Virtualization of rr's required PMU features on Azure and GCP -- Virtualization of Intel's CPUID faulting on AWS and other cloud providers (Linux KVM has it, but it's not enabled in AWS) -- Fix the reliability bug(s) in the retired-conditional-branches counter on AMD Ryzen so rr works there -- Implement CPUID faulting in AMD Ryzen -- Reliable instructions-retired counter on AMD/Intel (for more reliable/simpler operation) -- Trap on LL/SC failures on ARM (AArch64 I guess) and other archs (so we can port rr there), with Linux kernel APIs to expose that to userspace…

Paper and discussion history. A mention is not an endorsement.

Engineering Record And Replay For Deployability: Extended Technical Report — mentioned by garaetjjte

Wed, 27 Nov 2019 15:16:59 GMT

By capturing all external inputs to application, it can replay it many times and results will be always identical. https://arxiv.org/pdf/1705.05937

Paper and discussion history. A mention is not an endorsement.

Engineering Record And Replay For Deployability: Extended Technical Report — mentioned by roca

Tue, 06 Nov 2018 15:21:55 GMT

You should read https://arxiv.org/abs/1705.05937 so you don't need to speculate. rr absolutely does guarantee that threads are scheduled the same way during replay as during recording, otherwise it wouldn't work at all on applications like Firefox which use a lot of threads. Also, rr definitely is very useful for debugging race conditions. For example Mozilla developers have debugged lots of race conditions using it. One thing that really helps is rr's "chaos mode", which randomizes thread scheduling in an intelligent way to discover possible races. See…

Paper and discussion history. A mention is not an endorsement.

Engineering Record And Replay For Deployability: Extended Technical Report — mentioned by scott_s

Tue, 06 Nov 2018 15:13:48 GMT

Being slower is not, I think, the major downside. It is that an entire class of errors - race conditions - are basically outside of the scope of the tool. Which is understandable! Race conditions are hard, and when I read about the tool, my first thought was "How are they handling race conditions?" and it turns out, essentially, they're not. But race conditions are also the hardest part about debugging multithreaded applications. I'm not sure if the tool ensures deterministic scheduling of threads on the single core, but I doubt that it does. If it does not, then playbacks will not be…

Paper and discussion history. A mention is not an endorsement.

Engineering Record And Replay For Deployability: Extended Technical Report — mentioned by pm215

Tue, 06 Nov 2018 14:15:51 GMT

rr has an "extended technical report" at https://arxiv.org/pdf/1705.05937.pdf which explains the principles it uses. In general they are inherently rather complicated -- in order to get to anything resembling useful speed of execution, you need to play clever tricks of one kind or another to avoid having to record absolutely everything about the process under debug.

Paper and discussion history. A mention is not an endorsement.

Engineering Record And Replay For Deployability: Extended Technical Report — mentioned by roca

Tue, 06 Nov 2018 14:11:02 GMT

The basic idea is the same as ReVirt, but there are a lot of different details because rr has to run as a pure user-space Linux application whereas ReVirt was baked into the hypervisor. For rr to run efficiently we have to use Linux APIs in creative ways. https://arxiv.org/abs/1705.05937 has more details.

Paper and discussion history. A mention is not an endorsement.

Engineering Record And Replay For Deployability: Extended Technical Report — HN submission

Thu, 18 May 2017 23:35:45 GMT

Engineering Record and Replay for Deployability: Extended Technical Report

1 point; 0 discussion replies on HN. Paper and source history. A submission is not an endorsement.