[glandium]

OTOH, what rr also brings to the table is reverse debugging, and that makes these kinds of torturous debugging an order of magnitude easier.

So not only are you able to reproduce the error, but you're also able to go backwards to find how it happened!

I, for one, barely use gdb anymore because reverse debugging with rr makes debugging so much easier (well, technically, I still do use it, since rr is not an entirely new debugger, you still end up in with a gdb prompt).

FWIW, one of the first things I tried when I first used rr was to debug a crash I had debugged years earlier, that was due to a miscompilation by GCC. As that had happened years earlier, I didn't remember the details of what code was miscompiled in what particular way, but I do know that debugging that took a long time, and I had only figured it out by chance because valgrind pinpointed to related code. With rr it only took minutes to find the root of the crash.

[DannyBee]

"So not only are you able to reproduce the error, but you're also able to go backwards to find how it happened!"

For some (and i'd guess a bunch of the people i mentioned in the parent comment), they definitely find this easier, but just to present a contrarian position: i actually don't. I admit to being weird - in a former life, i was a gdb maintainer.

I also was trained by people who believed the right approach was not to immediately try to find the sets of conditions and variables that caused your problem and declare victory, but to go and meditate upon the code and think about it until you understood it well enough to understand why this might happen even when you think it couldn't. That will often enable you to understand the code well enough to see what else is wrong.

(Again, i don't claim it's better, i just claim that's why i tend not to care about RR. The hard part for me is the thinking about the code, not the finding the sets of conditions and variables that caused a particular set of errors)

It's definitely the case that, personally, when i follow the "find conditions, fix bugs" approach, i tend to write much buggier code (even with good testing strategies) than when i follow the other way.

[roca]

This reminds me of Linus Torvalds' distaste for debuggers.

I think eschewing debugging is fine for code you understand pretty well and when you already have significant information about the failure. But when those conditions aren't met, debuggers are very useful. (NB, if you use logging code and think "I'm not using a debugger!", you're just using a bad one.)

It's true that a good debugger tempts one to think less deeply about the code than one should, but that temptation can be overcome.

[voltagex_]

I wonder if there's a 'hello world' for rr - something funky that is made simple by being able to step in reverse. It's definitely very useful in Visual Studio.

[roca]

Any heap memory corruption bug is a great example for rr. Replay the failure, spot the corrupt location, set a data watchpoint on it, "reverse continue", and you'll stop where the corruption happened. The same bug is generally horrible to find using a regular debugger.

The Visual Studio feature you mention is probably Intellitrace, which is considerably more limited than rr and doesn't handle heap state.