3 ms·
https://rr-project.org https://rr-project.org This is indeed a problem people have with debuggers, so some very smart people found a way to fix it.
by plorkyeran 3y ago
https://rr-project.org https://rr-project.org
This is indeed a problem people have with debuggers, so some very smart people found a way to fix it.
- thrtythreeforty 3y agorr 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.
- LegionMammal978 3y agoIndeed, 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.
- gchirag2 3y agoWe'd be hosting the RR inventor to a tech talk soon! I'll post a link here when we have it scheduled
- gregthelaw 3y ago> 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 https://undo.io)