Description Dave 2004-03-23 11:31:54 EST

Add back-in-time support to the debugger. This facility would add a "backwards"
version of each of the typical step forward statements: step-into, step-over,
step-out-of-method, run to cursor.

This would likely involve saving some representation of the state of memory in a
list (though saving the entire state would take prohibitively excessive space;
probably just record changes to memory each step), with each list element
representing the execution of one line of code. This list can be traversed if
the user steps back in order to recover the state of the system at any previous
point of execution. Stepping back and then forward again would not actually run
the code again; it would simply remember the state of the system the first time
the code was run and restore the state. Therefore running non-deterministic or
time-dependent statements (calls to Intel's hardware random number generator,
System.getCurrentTimeMillis()) would produce identical results on subsequent
step-forward actions.

This would be useful to detecting the cause of crashes when the "actual" cause
is far from the "direct" cause. For example, attempting to call a method on a
null object reference "directly" causes a NullPointerException, but the "actual"
cause is the assignment of a null value to a variable at an earlier, and perhaps
far-removed, point in the code. Currently, tracking the "actual" cause of the
bug involves running from the beginning of execution and eyeballing the variable
(or an entire set of variables that may affect the offending variable) to see
when the system enters an invalid state, or sprinkling the code with asserts to
try to get the system to fail at a point closer to the "actual" cause. A
back-in-time debugger allows one to debug in a more natural way by starting from
the error, where the system state is known to be invalid, and stepping back
until the system transistions from invalid state to valid.

This should also be an option that can be disabled, since it will require much
more memory than a typical debugger.

I have no idea how difficult this is to implement, but these people did it:
See http://www.omnicore.com/debugger.htm