rr icon indicating copy to clipboard operation
rr copied to clipboard

Rework trace storage

Open rocallahan opened this issue 7 years ago • 5 comments

The current trace storage approach has some issues that we need to fix:

  • Traces are written directly by the rr process and buffered data is not always flushed, so SIGKILL directed at the rr process (not uncommon, when rr is used as a wrapper around some program that normally is SIGKILLed by other code, e.g. on timeout) leaves an unusable trace.
  • rr must finish writing a trace before anything can start consuming the trace. If we fixed this then you could start an rr replay concurrently with an rr record and be ready to debug as soon as an error is encountered instead of having to wait for the replay.
  • There is no currently way to efficiently package a trace for copying or streaming to another machine for replay.
  • Currently trace versioning is very primitive and there is no way for rr replay to consume trace versions other than the 'current' version.

On the other hand it has some important features we need to preserve:

  • We avoid copying data by hardlinking and FICLONERANGEing files into the trace directory.
  • Certain data records like memory-maps and trace-events are stored in their own files so tools can efficiently read those records without having to scan the whole trace.

rocallahan avatar Dec 01 '16 10:12 rocallahan