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.
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.
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.
GDB reverse debugger is very slow as it is saving the execution state after every instruction executed.
There is a commercial plugin for GDB reverse debugger: UndoDB. It is much faster than just GDB (they claim only 1.7x slowdown), but unfortunately not very stable for the product I'm working on.
I'm a co-founder of the company. Lots of stability improvements over the past year or so: I'd urge you to try it again. Particularly v4 beta. Send email to beta@undo-software.com to get a beta license.
I'd never claim it's perfect: it's software after all, and the fact most software has bugs is why we have a business in the first place ;) But we're used by some pretty hardcore folk these days, including Cadence, NASA, and some of the biggest banks in the world. And the PyPy guys seem pretty happy :) Oh, and of course, if you do find issues, please do report them to support@undo-software.com -- then we can fix them.
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].
