> Indeed, that fixes the part about it only marching forward. But still, it wouldn't be sufficient in cases where the ultimate cause is near neither the start nor the obvious error, but (e.g.) in the 50th of 100 entries.
Not true. rr (and time travel debugging in general) really excels at exactly that problem. You just put a watchpoint on the offending data at the 'obvious error', and reverse-continue. This usually takes you straight to the root-cause. It's incredibly powerful.
(Disclaimer, I'm not exactly unbiased as I work on another time-travel debugger, https://undo.io)
Indeed, that fixes the part about it only marching forward. But still, it wouldn't be sufficient in cases where the ultimate cause is near neither the start nor the obvious error, but (e.g.) in the 50th of 100 entries. At least, not unless the initial error is simple enough to be captured by a conditional breakpoint. But even then, I'd probably be reaching for my prints just to determine what a good condition might be.
rr is so good. "Where was this variable written? Where did this value come from?" Set watchpoint, reverse-continue, and bam you arrive at where the write happened.
This is indeed a problem people have with debuggers, so some very smart people found a way to fix it.