Instant replay: Debugging C and C++ programs with rr (Red Hat Developer)

Posted May 4, 2021 17:37 UTC (Tue) by tux3 (subscriber, #101245)
In reply to: Instant replay: Debugging C and C++ programs with rr (Red Hat Developer) by SLi
Parent article: Instant replay: Debugging C and C++ programs with rr (Red Hat Developer)

The traces are manageable, as long as you try to keep it to a few minutes max. It's not fast by any means (has to run single threaded), but it's not valgrind levels of slow. It's made to be usable even for browsers (which should give a good workout to any tool ptracing them).

AAIU rr takes a snapshot every second or so, so that reverse-continuing can rust fast. So that _would_ be a lot of data, but they compress it and you gain back about an order of magnitude.

Instant replay: Debugging C and C++ programs with rr (Red Hat Developer)

Posted May 4, 2021 17:44 UTC (Tue) by SLi (subscriber, #53131) [Link] (2 responses)

Ok. Probably a bit unmanageable for me then data amount wise (GDB already slows things down; I guess rr might not be that much worse?); I tend to work with KiCad for hours.

I tried running KiCad under it. It at least started fast, but died almost immediately, apparently because it uses shared memory, which is IIUC fundamentally incompatible with rr:

```
$ rr record kicad spkr_interface.kicad_pro
rr: Saving execution to trace directory `/home/sliedes/.local/share/rr/kicad-0'.
shared memfd open() failed: Function not implemented
[... some kicad messages]
Trace/breakpoint trap
```

Instant replay: Debugging C and C++ programs with rr (Red Hat Developer)

Posted May 4, 2021 23:38 UTC (Tue) by roc (subscriber, #30627) [Link] (1 responses)

Can you file an rr issue and paste the entire console log? It might not be related to the "shared memfd open" message.

Instant replay: Debugging C and C++ programs with rr (Red Hat Developer)

Posted May 5, 2021 13:05 UTC (Wed) by SLi (subscriber, #53131) [Link]

Done: https://github.com/rr-debugger/rr/issues/2849

Instant replay: Debugging C and C++ programs with rr (Red Hat Developer)

Posted May 4, 2021 18:27 UTC (Tue) by MattBBaker (guest, #28651) [Link] (2 responses)

How much detail does RR retain? Like, if I step back 10,000 instructions then what will I see from 'info registers'?

Instant replay: Debugging C and C++ programs with rr (Red Hat Developer)

Posted May 4, 2021 19:44 UTC (Tue) by bjacob (guest, #58566) [Link]

rr should show you the exact correct values in `info registers` at any time, yet that does not require storing that much information. The basic idea of rr is that most instructions in a program are deterministic, the only non-determinism is localized at relatively few points in the program's execution (typically: I/O). So in order to allow you to rewind back to any point and show the correct values in `info registers`, rr only needs to state from those relatively few non-determinism sources, rewind back to there, then re-play forward from there.

Instant replay: Debugging C and C++ programs with rr (Red Hat Developer)

Posted May 4, 2021 23:50 UTC (Tue) by roc (subscriber, #30627) [Link]

rr replay reproduces the exact memory and register contents* of the recording at every point during program execution.

* There are some very small exceptions in our accelerated syscall interception machinery that are irrelevant in practice.

Instant replay: Debugging C and C++ programs with rr (Red Hat Developer)

Posted May 4, 2021 23:39 UTC (Tue) by roc (subscriber, #30627) [Link] (1 responses)

FWIW rr recording does not take snapshots. rr *replay* with gdb does, but we only keep around a few at a time and we use fork() so they're mostly copy-on-write, so their memory overhead is never an issue in practice.

Instant replay: Debugging C and C++ programs with rr (Red Hat Developer)

Posted May 5, 2021 11:58 UTC (Wed) by tux3 (subscriber, #101245) [Link]

Thank you for the clarification!