3 ms·
From memory rr has a substantive recording overhead, and is specially made for debugging, right? But yes it is very useful to analyse a past state and to unders
by touisteur 5y ago
From memory rr has a substantive recording overhead, and is specially made for debugging, right? But yes it is very useful to analyse a past state and to understand a chain of events.
I should clarify my use case: I would use such a feature (go back to previous state) for a speculative execution tool. I'd execute the happy path all the time assuming no error occured, but if I found out later that something went wrong somewhere, I'd want to go back and start from there knowing what went wrong, and so on. With as little perf loss as possible. Not sure my explanation makes sense.
I know about dmtcp, criu, vm snapshots, but they all come with big overhead (I don't want to pay too much for the checkpoint).
The closest I found was @gamozolabs amazing work on snapshot fuzzing (pushing the limit of what's possible on x86_64 hardware, including using Intel PML - similar to userfaultfd but hw-accelerated...).
- Agingcoder 5y agoRr was initially designed to reproduce flaky tests I think. They then realized that they could modify it for reverse debugging. The recording overhead is quite acceptable, about 50%. Rr also has a 'chaos mode' which changes the thread scheduling, and which greatly facilitates finding the 'unhappy' path.
- touisteur 5y agoOK thanks for the feedback on recording overhead, I'll have to try for the checkpoint/restore use case.
- Agingcoder 5y agoYou might be interested by pernosco, written by the same people. It's rather spectacular. https://pernos.co https://pernos.co The recording overhead is the same (it leverages rr) but you can explore your bug to your heart's content.