3 ms·

For me, the most annoying part about a debugger is that it always shows a snapshot at a single point in time, and the snapshot can only march forward. A good fr

For me, the most annoying part about a debugger is that it always shows a snapshot at a single point in time, and the snapshot can only march forward. A good fraction of bugs in my code are ones that surface gradually or occasionally over a long sequence of operations. Stopping at the ultimate failure point is far too late, and breaking at every single iteration is far too tedious. But with a log of all the iterations, I can trace the error back to the initial point where the program no longer acts as expected. That is, I very often find a narrow view of the program state over the whole computation to be more informative than a wide view of the program state at any particular moment in time.

c-st 3y ago
In some cases, GDB allows reverse execution of code: https://sourceware.org/gdb/current/onlinedocs/gdb.html/Reverse-Execution.html https://sourceware.org/gdb/current/onlinedocs/gdb.html/Rever...
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 ago
  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.
- LegionMammal978 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. 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 ago
  We'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)

c-st 3y ago

In some cases, GDB allows reverse execution of code: https://sourceware.org/gdb/current/onlinedocs/gdb.html/Reverse-Execution.html https://sourceware.org/gdb/current/onlinedocs/gdb.html/Rever...

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 ago
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.
LegionMammal978 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. 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 ago
We'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)