I never used a debugger that can run a program backwards but I would like to. Now I wonder if there is much evidence and theory about backwards runnable programming, when and why a program can be run backwards or when and why not?

Intuitively I find that the computer should be able to run the program backwards, if it once has run the program forward knowing that the program will run backwards hence saving states of the program that otherwise might get lost and deallocated.

Debugging is just a practical example. I'm also interested in it for the sake of the theory of reversibility, if the program can be run backwards, then what the program does is reversible, isn't it?

  • 1
    $\begingroup$ I've been thinking about reverse debugging before from a practical perspective. I think it would be a killer plugin for any IDE. There are some obvious initial observations: 1. When writing to a variable in forward mode, you need to store it's previous state (e.g. this costs ~2.4 GB memory / s). 2. If you want to avoid the extra memory, you can rerun the program up to the line you want to debug back to. 3. You can make a tradeoff between the previous two points. 4. It doesn't work if the program has side effects, such as making a REST call. $\endgroup$ – Albert Hendriks May 14 '16 at 7:58

In theory, to actually run program backwards would require you to undo any effects of program execution. Doing that should be relatively simple, if inefficient, for memory changes, harder for changes on disk and impossible for networking. And if the code depends on any external state (time of day, file on disk that could be modified by another process), rewinding and running it again won't produce the same result.

In practice, what is possible is to allow you to look at the state of the program at some point in its execution, but without allowing you to restart from that point. This way, there are no problems with external state, because this form of rewinding doesn't need to undo any state changes (except for memory) and stepping forwards will always produce the same result (because the code is not actually executed again). This form of rewinding is implemented in Visual Studio, under the name Historical Debugging, though it doesn't record program state at every instruction or line of code, only at every method call.


There's lots of research on this subject. I've sometimes seen it called "time-travel debugging" in the literature, sometimes "reverse debugging". A few minutes on Google Scholar should turn up a bunch of research publications on the subject.

See also https://softwareengineering.stackexchange.com/q/181527/34181 and https://stackoverflow.com/q/1470434/781723.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.