5 ms·
You probably could record a process running for days but it would also take days to replay to the end, which would not be much fun. We don't create checkpoints
by roca 4y ago
You probably could record a process running for days but it would also take days to replay to the end, which would not be much fun. We don't create checkpoints during the recording.
You'd be better off restarting the recording periodically. Also, rr has a "chaos mode" which randomizes scheduling and often makes threading bugs easier to reproduce. https://robert.ocallahan.org/2016/02/introducing-rr-chaos-mode.html https://robert.ocallahan.org/2016/02/introducing-rr-chaos-mo...
- pm215 4y agoHmm, when I asked for 'replay -e' I thought it would be faster than 'type run and wait' -- is it not?
- roca 4y agoNo.
- Agingcoder 4y agoChaos mode works quite well in my experience, definitely worth trying if you don't want to wait for days. I had a heisenbug which would appear once a week, and that I couldn't trigger on my workstation. Chaos mode did the trick.
- anarazel 4y agoI've found that the scheduling quanta with chaos mode are too high to hit concurrency issues in a reasonable amount of time. And IIUC --num-cpu-ticks is not randomized. So if something happens below that tick quantum it's hard to hit. I wonder if a) rr could randomize the cpu ticks as well, at least in chaos mode, b) profiled code could somehow hint to rr that a certain instruction would be an "interesting" scheduling point.
- roca 4y agoChaos mode varies the scale of the tick quantum to try to catch stuff like that. It doesn't always work, especially if the window of vulnerability to the bug is incredibly small (e.g. a few instructions).