

Reverse Debugging with GDB - mrmaddog
http://sourceware.org/gdb/wiki/ReverseDebug

======
coldcode
Reverse debugging sounds like putting bugs in. We do that every day already.

------
fijal
We (PyPy developers) tried this and it's unusably slow. I don't know how they
got that slow, but it takes a bit forever to execute 10mln instructions. We
ended up using UndoDB gdb wrapper, which runs slower than they advertise (+-
the same speed as valgrind so say 30x give or take), but is a lot more usable.
They had stability problems in the past, but with the recent versions, we're
able to run stuff like complex python programs on top of pypy on top of
UndoDB, which is very impressive. Very useful for hard GC bugs.

------
bravura
I have a more modest request:

Could debuggers please store the code paths and variable values, over the last
50 executions or perhaps the test suite (deterministic)? This is particularly
useful for understanding someone else's code.

[edit: a context-free version of reverse debugging]

I've recently been enjoying using IntelliJ for Scala, because it can show me
types, and jump to type declarations, and usages.

However, I still have to do a bunch of print debugging when trying to
understand someone else's code, because I want to understand what values
certain variables take. This is a pain using a compiler as slow as Scala.

Something that captured relevant information, so that it would be easier +
faster to do print debugging against previous code runs or the test suite,
would be awesome.

~~~
jbert
It looks like the underlying feature which enables reverse debugging, Process
Recording, could do what you describe:

[https://sourceware.org/gdb/wiki/ProcessRecord](https://sourceware.org/gdb/wiki/ProcessRecord)

the data may only be in-process, if so it would need to be save-able and load-
able.

------
neur0mancer
I tried it. Unfortunately, it is very slow.

~~~
adamnemecek
It is. But that one time when you will be dealing with a Heisenbug, you will
be thankful for it.

~~~
ginko
The thing with Heisenbugs is that they usually don't happen when you attach a
debugger.

~~~
adamnemecek
That kind of depends. They can also happen not because you attached a debugger
but because you set a break point in a particularly unfortunate location.

~~~
RobotCaleb
Oh man. I spent a couple of days tracking one of those down. When the light
went on in my head I felt like such an idiot.

------
Groxx
For Java, if it still runs:
[http://www.lambdacs.com/debugger/](http://www.lambdacs.com/debugger/)

I really like the idea. Never knew GDB had implemented it (thanks for the
link!). I'll _definitely_ try this out :)

------
martin_
I'm assuming this wasn't a big hit as little as been mentioned about it since
its release in 2009?

~~~
jlebar
IME it's not only slow, but also very memory-hungry. As a result it's hard to
use it to debug heisenbugs, because you have to have a decent idea of where
the bug is, so you can start recording at that point. But of course if you
know even roughly where the bug was, debugging isn't nearly as hard...

VMWare had record-and-replay debugging functionality which was functionally
similar to gdb's backwards debugging, although its implementation was a lot
different, which allowed it to scale to recording much longer threads of
execution. We used this at Mozilla to find a number of super-tricky bugs; it
was pretty awesome. Unfortunately this feature was nixed in vmware workstation
8 [1].

[1] [http://www.replaydebugging.com/](http://www.replaydebugging.com/)

~~~
martin_
That's very interesting! Why did they remove that feature if it was so
awesome?

------
peterhajas
Cool! Does `lldb` have similar functionality?

