3 ms·
gdb's reverse execution is incredibly slow. Performance overhead of reverse debuggers: * gdb: >1000x (note: I never tested this one myself; just heard about t
by ynik 4y ago
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)
- fanf2 4y agoThere is also a commercial alternative, https://undo.io/solutions/products/udb/ 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.)
- zempfel 4y agoI 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.
- ynik 4y agoI 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)
- ncmncm 4y agoWould we recognize the blamed library?