Hacker News Reader

Comment by bajsejohannes | Hacker News Reader

That feels like it's underselling it a bit, since gdb does not have reverse execution, which is a pretty major contribution by rr.

View on HN

AIUI, Gdb does claim reverse execution, for certain targets. So, there are differences, but I don't understand them.

gdb's reverse execution is incredibly slow.

Performance overhead of reverse debuggers:

* gdb: >1000x (note: I never tested this one myself; just heard about this overhead in a HN comment a long time ago)

* Microsoft WinDbg TimeTravel Debugger: >40x

* rr: 1.5x

rr is the only one fast enough to be used on a regular basis -- the others are slow enough that they only make sense on particularly nasty bugs (usually memory corruption)

There is also a commercial alternative, https://undo.io/solutions/products/udb/ though I have not used it myself and I don’t know what its overhead is. (I know some of the people who work on it.)

I would be surprised if the overhead of TTD is typically 40x, given that it records multithreaded processes in parallel. Which, to my knowledge, rr does not.

It also supports selective recording so, if this is configured (e.g. selecting certain functions), only a subset of the process execution is actually committed to the trace file, further reducing the overhead.

I don't know about multithreaded processes -- the program I use it is single-threaded. My main use case is not to make the crashes reproducible (they usually already are), but to understand where a bogus value is coming from. (memory breakpoint + run backwards) Which often ends up being a certain third-party library that makes liberal use of C unions, sometimes accessing the wrong variant...

I'll have to look into selective recording, but I'm not sure how helpful it'll be in my use case (I don't know said library well enough to predict which functions might be causing the bogus values)

Would we recognize the blamed library?

gdb claims it. I have not once ever gotten it to work, however. For anything seemingly larger than a trivial program, the reverse-execution state grows too big and needs to be pruned. I also don't think it supports such fancy things as "floating point".

Using GDB’s reverse execution requires you to already be pretty sure where the bug you are looking for is, and then recording a very short portion of the program, preferably just 10k instructions or so. Recording for a whole second could easily take 15 minutes. But it does work well, within those limitations.

> gdb does not have reverse execution

GDB does have reverse execution:

https://sourceware.org/gdb/current/onlinedocs/gdb/Reverse-Ex...

Reply on news.ycombinator.com