Re: Replay debuggers

"Dmitry Shaporenkov" <dsha@tercom.ru> writes:


>I'm interesting in information about replay debuggers (i.e., debuggers
>that allow 'backward execution' of debugging program by checkpointing
>of its state and restoring an old state later), especially
>implementation techniques on various platforms. The only example I
>currently know is ocamldebug, but it heavily relies on the presence of
>fork() system call and therefore seems to be not portable.


The Mercury implementation includes support for replay debugging. See
[1] and [2]. It is a very useful feature -- I make substantial use of
it virtually every time I use the debugger.


The implementation does not use the fork() system call.
Instead, it relies on the side effect free nature of Mercury programs.
In Mercury, most procedures do not depend on or modify global state
or perform destructive updates on data structures. Mercury's type
and mode system allows the debugger to identify those which do.
The debugger's "retry" command enables the user to restart the execution
of a procedure call. The debugger only allows this for procedures
whose type and mode indicates that they do not perform unrecoverable
destructive updates.


Mercury supports two kinds of destructive updates, "trailed" and "untrailed".
Trailed updates record information in a data structure called the "trail"
which can be used to restore the state on backtracking. The debugger's
"retry" command therefore supports retrying of procedures which perform
trailed updates -- the updates are unrolled using the trail.
Retrying is disallowed only for procedures that perform untrailed updates.


I/O is treated as a special case of untrailed destructive update.
In this case, it is sometimes safe to just re-redo the I/O when
the procedure is retried. So in this case, the debugger prints a
warning message and asks the user if they are really *really* sure ;-),
and if the user says yes, then the retry is permitted, although
it's not guaranteed to preserve the program's semantics.


Most Prolog implementations also support a similar feature. However,
it only works if the Prolog procedure being retried really is side
effect free, and unlike with Mercury, neither the debugger nor the
compiler will check that this truly is the case. When I was doing
serious Prolog programming, I started out using it, but eventually gave
up. Sometimes it was very useful, but overall I found it to be a net loss.
The reason was that I spent too much time chasing non-bugs caused by
trying to use this feature on procedures which in fact had side effects
hidden away in their implementation details. In Prolog, unlike Mercury,
there's no static analysis of which procedures might have side effects.


Mark Brown <dougl@cs,mu,oz,au> has also been working on more general
support for replay debugging of (single-threaded) .NET executables
using an IL-to-IL transformation. The idea here is to make use of
trailing to handle updates to data structures, and memoization to
record results of I/O. When backtracking, updates to data structures
get undone, and then during repeat forward execution, I/O primitives
will use the memo table to return the same result as previously without
redoing the I/O.


References


[1] The implementation technology of the Mercury debugger.
Zoltan Somogyi and Fergus Henderson.
Proceedings of the Tenth Workshop on Logic Programming Environments,
Las Cruces, New Mexico, November 1999, pages 35-49. Available at
<http://www.cs.mu.oz.au/research/mercury/information/papers.html>.
In particular, see section 3.4 -- although you probably have to read
the earlier parts of the paper first to make sense of it.


[2] The "Debugging" chapter of the Mercury user's guide. Available at
<http://www.cs.mu.oz.au/research/mercury/information/documentation.html>.
The replay debugging commands are documented in the "Backward movement
commands" sub-section of the "Debugger Commands" section.


--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.

Return to the comp.compilers page.
Search the comp.compilers archives again.