Hacker News new | past | comments | ask | show | jobs | submit login

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...).




Rr 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.


OK thanks for the feedback on recording overhead, I'll have to try for the checkpoint/restore use case.


You might be interested by pernosco, written by the same people. It's rather spectacular.

https://pernos.co

The recording overhead is the same (it leverages rr) but you can explore your bug to your heart's content.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: