Re: Using reverse execution

[Michael Snyder <michsnyd@cisco.com>]

 >> That's not what you do when you trace a bug.  You start from
 >> the place where, e.g., the program gets a SIGSEGV, and then
 >> unroll it back to possible places where the corruption could
 >> have happened.  That is, you try to guess where the problem
 >> could have originated from, and then get there and look around
 >> for clues.  I don't find this jarring in any way.
 >
 > But have you actually done any debugging by reverse execution
 > yourself?

I have.  I've been using it to debug real bugs, difficult ones,
in a realtime embedded OS.  I've got a prototype gdb working
with the Simics simulator, with all of the reverse-* commands
pretty much working: reverse-continue, step, stepi, next,
nexti, and finish.  Breakpoints and watchpoints also work
in reverse.

I'll give you my best example, which follows a scenario
that Stan outlined near the beginning of this thread.

I've got multiple threads, and one of them is blowing its
stack.  Unfortunately it doesn't cause an immediate problem --
it isn't detected until the scheduler does a sanity check at
the next task switch point, and discovers that the guard word
at the end of the stack is gone.  At that point, it panics.
This is essentially like seg faulting when you write thru a
bad pointer -- you need to know who wrote the bad value to
the  pointer, and that will be the LAST person who changed
it.  Many people may have changed it before then.

But -- all I had to do was run forward until the stack
corruption was detected (by analogy, to the segfault),
and then put a watchpoint on the clobbered memory
location and run backward.  Bingo -- the first time
the watchpoint triggers, I have my culprit.

Michael Snyder
(still at Red Hat, don't be confused by the email address)