Mailing List Archive: Python: Python

Reversible Debugging

Index | Next | Previous | View Threaded

patrick.just4fun at gmail

Jul 3, 2009, 11:18 AM

Post #1 of 13 (824 views)
Permalink

Reversible Debugging

Hello,

I am interested if there are any python modules, that supports
reversible debugging aka stepping backwards. Any links or ideas would be
helpful, because I am thinking of implementing something like that.

Thanks in advance,
Patrick
--
http://mail.python.org/mailman/listinfo/python-list

gagsl-py2 at yahoo

Jul 3, 2009, 9:04 PM

Post #2 of 13 (787 views)
Permalink

Re: Reversible Debugging [In reply to]

En Fri, 03 Jul 2009 15:18:51 -0300, Patrick Sabin
<patrick.just4fun [at] gmail> escribió:

> I am interested if there are any python modules, that supports
> reversible debugging aka stepping backwards. Any links or ideas would be
> helpful, because I am thinking of implementing something like that.

Do you want reverse execution, like an undo function? Undo all changes
made by executing some piece of code?
There are many cases where that's hard to do, or impossible. How to undo
object destruction? How to undo external effects, like writing to files?
You should think carefully what can and cannot be done - good luck!

--
Gabriel Genellina

--
http://mail.python.org/mailman/listinfo/python-list

tkjthingone at gmail

Jul 3, 2009, 11:46 PM

Post #3 of 13 (776 views)
Permalink

Re: Reversible Debugging [In reply to]

You might consider using a VM with 'save-points'. You run the program (in a
debugger/ida/what have you) to a certain point (logical point would be
if/ifelse/else statements, etc) and save the VM state. Once you've saved,
you continue. If you find the path you've taken isn't what you are after,
you can reload a previous save point and start over, trying a different path
the next time.

This is also somewhat useful if you're trying to debug an error that happens
deep inside of a program, so you can continually jump to the point right
before the error happens, instead of needing to run through the entire
program each time it crashes. Just beware of tunnel vision.

patrick.just4fun at gmail

Jul 4, 2009, 1:04 AM

Post #4 of 13 (775 views)
Permalink

Re: Reversible Debugging [In reply to]

Gabriel Genellina schrieb:
> Do you want reverse execution, like an undo function? Undo all changes
> made by executing some piece of code?
I am not completly sure, if I really want to make exact undo, i.e.
undoing commands by reversing all their effects, or just restoring the
program state to an arbitrary state of its history, which would not
effect things like files.
> There are many cases where that's hard to do, or impossible. How to
> undo object destruction? How to undo external effects, like writing to
> files?
Object destruction should not be a big problem to restore. But writing
files or other resources is because it is not guaranted that it is even
possible or wanted.
I considered either ignoring undoing external commands completly or
adding some plugin system to do it.
> You should think carefully what can and cannot be done - good luck!
>
--
http://mail.python.org/mailman/listinfo/python-list

patrick.just4fun at gmail

Jul 4, 2009, 1:33 AM

Post #5 of 13 (790 views)
Permalink

Re: Reversible Debugging [In reply to]

Horace Blegg schrieb:
> You might consider using a VM with 'save-points'. You run the program
> (in a debugger/ida/what have you) to a certain point (logical point
> would be if/ifelse/else statements, etc) and save the VM state. Once
> you've saved, you continue. If you find the path you've taken isn't
> what you are after, you can reload a previous save point and start
> over, trying a different path the next time.
That was my idea to implement it. I thought of taking snapshots of the
current state every time a "unredoable instruction", e.g random number
generation, is done. For every other instruction I count the number of
instructions done since the last snapshot. So I can go back one
instruction by restoring to the previous state and go the number of
instructions minus one forward.

> This is also somewhat useful if you're trying to debug an error that
> happens deep inside of a program, so you can continually jump to the
> point right before the error happens, instead of needing to run
> through the entire program each time it crashes. Just beware of tunnel
> vision.
I think of implementing some snapshot/restore mechanism first. That may
help in many other situations.
--
http://mail.python.org/mailman/listinfo/python-list

stef.mientki at gmail

Jul 4, 2009, 2:25 AM

Post #6 of 13 (772 views)
Permalink

Re: Reversible Debugging [In reply to]

Patrick Sabin wrote:
> Hello,
>
> I am interested if there are any python modules, that supports
> reversible debugging aka stepping backwards. Any links or ideas would
> be helpful, because I am thinking of implementing something like that.
>
In some cases it would be nice to have something like that,
specially in combination with a "normal" debugger,
which allows you to change values on the flight,
like winpdb.

cheers,
Stef
> Thanks in advance,
> Patrick

--
http://mail.python.org/mailman/listinfo/python-list

Scott.Daniels at Acm

Jul 4, 2009, 5:31 AM

Post #7 of 13 (773 views)
Permalink

Re: Reversible Debugging [In reply to]

Patrick Sabin wrote:
> Horace Blegg schrieb:
>> You might consider using a VM with 'save-points'. You run the program
>> (in a debugger/ida/what have you) to a certain point (logical point
>> would be if/ifelse/else statements, etc) and save the VM state. Once
>> you've saved, you continue. If you find the path you've taken isn't
>> what you are after, you can reload a previous save point and start
>> over, trying a different path the next time.
> That was my idea to implement it. I thought of taking snapshots of the
> current state every time a "unredoable instruction", e.g random number
> generation, is done.
Remember, storing into a location is destruction.
Go over a list of VM instructions and see how many of them are undoable.
--
http://mail.python.org/mailman/listinfo/python-list

davea at ieee

Jul 4, 2009, 6:58 AM

Post #8 of 13 (768 views)
Permalink

Re: Re: Reversible Debugging [In reply to]

Scott David Daniels wrote:
> <div class="moz-text-flowed" style="font-family: -moz-fixed">Patrick
> Sabin wrote:
>> Horace Blegg schrieb:
>>> You might consider using a VM with 'save-points'. You run the
>>> program (in a debugger/ida/what have you) to a certain point
>>> (logical point would be if/ifelse/else statements, etc) and save the
>>> VM state. Once you've saved, you continue. If you find the path
>>> you've taken isn't what you are after, you can reload a previous
>>> save point and start over, trying a different path the next time.
>> That was my idea to implement it. I thought of taking snapshots of
>> the current state every time a "unredoable instruction", e.g random
>> number generation, is done.
> Remember, storing into a location is destruction.
> Go over a list of VM instructions and see how many of them are undoable.
>
> </div>
>
>
Read his suggested approach more carefully. He's not "undoing"
anything. He's rolling back to the save-point, and then stepping
forward to the desired spot. Except for influences outside his control
(eg. file system operations), this approach has to work. Even random
will work the same, if the generator uses only data that was restored
from the save-point. A typical pseudo-random generator works from a
seed, and if the seed is restored as part of rolling back, he's fine.
If the snapshot is done via VMWare (for example), he's even okay for
file operations, except for network and VM-shared files.

"I thought of taking snapshots of the current state every time a
"unredoable instruction", e.g random number generation, is done. For
every other instruction I count the number of instructions done since
the last snapshot. So I can go back one instruction by restoring to the
previous state and go the number of instructions minus one forward."

DaveA

--
http://mail.python.org/mailman/listinfo/python-list

steve at REMOVE-THIS-cybersource

Jul 4, 2009, 7:10 AM

Post #9 of 13 (771 views)
Permalink

Re: Reversible Debugging [In reply to]

On Sat, 04 Jul 2009 09:58:39 -0400, Dave Angel wrote:

> Read his suggested approach more carefully. He's not "undoing"
> anything. He's rolling back to the save-point, and then stepping
> forward to the desired spot. Except for influences outside his control
> (eg. file system operations), this approach has to work.

Is that anything like saying "Except for all the diseases this drug won't
cure, it cures everything"?

*wink*

--
Steven
--
http://mail.python.org/mailman/listinfo/python-list

Scott.Daniels at Acm

Jul 4, 2009, 8:03 AM

Post #10 of 13 (760 views)
Permalink

Re: Reversible Debugging [In reply to]

Dave Angel wrote:
> Scott David Daniels wrote:
>> Patrick Sabin wrote:
>>> Horace Blegg schrieb:
>>>> You might consider using a VM with 'save-points'. You run the
>>>> program (in a debugger/ida/what have you) to a certain point
>>>> (logical point would be if/ifelse/else statements, etc) and save the
>>>> VM state. Once you've saved, you continue. If you find the path
>>>> you've taken isn't what you are after, you can reload a previous
>>>> save point and start over, trying a different path the next time.
>>> That was my idea to implement it. I thought of taking snapshots of
>>> the current state every time a "unredoable instruction", e.g random
>>> number generation, is done.
>> Remember, storing into a location is destruction.
>> Go over a list of VM instructions and see how many of them are undoable.
> Read his suggested approach more carefully. He's not "undoing"
> anything. He's rolling back to the save-point, and then stepping
> forward to the desired spot.
Right, I did misread "unredoable" as "undoable." However, I suspect a
surprising amount of stuff is "unredoable" -- iff the random number
generator counts as one of those things. The random number seeder is
unredoable with empty args, but running the generator once seeded is
predictable (by design). If you don't capture the random number state
as part of your "snapshot," _lots_ of C space storage will be in the
same class, and you are stuck finding the exceptional "safe to use"
cases, rather than the exceptional "unsafe to use." Similarly, system
calls about time or _any_ callback (when and where executed) create
snapshot points, and I suspect roll forwards will be relatively short.
In fact, in some sense the _lack_ of a callback is unredoable.

--Scott David Daniels
Scott.Daniels [at] Acm
--
http://mail.python.org/mailman/listinfo/python-list

davea at ieee

Jul 4, 2009, 9:09 AM

Post #11 of 13 (764 views)
Permalink

Re: Reversible Debugging [In reply to]

Steven D'Aprano wrote:
> On Sat, 04 Jul 2009 09:58:39 -0400, Dave Angel wrote:
>
>
>> Read his suggested approach more carefully. He's not "undoing"
>> anything. He's rolling back to the save-point, and then stepping
>> forward to the desired spot. Except for influences outside his control
>> (eg. file system operations), this approach has to work.
>>
>
> Is that anything like saying "Except for all the diseases this drug won't
> cure, it cures everything"?
>
> *wink*
>
>
>
<grin>
Yeah, pretty close. That's the problem with speaking in concepts,
rather than something concrete.

Somebody else brought up VM, but that has two meanings these days. The
sense I took it (with regard to save-point) was a program like VMWare,
where it virtualizes the entire machine. So any program that deals only
with the local machine will fit that approach. And yes, I know there
are subtleties beyond networks and virtual networks, like time. When
you roll the VM back, the time magically stays current. But for a
program that deals only with its own process, that tends to just look
like some other process suddenly hogged the CPU.

Now, if the snapshot is a feature of the Python VM, that's another
matter entirely.

--
http://mail.python.org/mailman/listinfo/python-list

patrick.just4fun at gmail

Jul 4, 2009, 10:21 AM

Post #12 of 13 (755 views)
Permalink

Re: Reversible Debugging [In reply to]

> Now, if the snapshot is a feature of the Python VM, that's another
> matter entirely.
I thought of taking a snapshot using fork, which creates a copy of the
process. It may not be the
most performant, but it should be quite portable. Of course there are
some issues with
multithreading/multiprocessing.

If someone has another idea of taking a snapshot let me know. Using
VMWare is not a
very elegant way in my opinion.

--
http://mail.python.org/mailman/listinfo/python-list

vilya.harvey at gmail

Jul 4, 2009, 10:53 AM

Post #13 of 13 (754 views)
Permalink

Re: Reversible Debugging [In reply to]

2009/7/4 Patrick Sabin <patrick.just4fun [at] gmail>:
> If someone has another idea of taking a snapshot let me know. Using VMWare
> is not a
> very elegant way in my opinion.

Someone implemented the same idea for Java a while ago. They called it
"omniscient debugging"; you can find details at
http://www.lambdacs.com/debugger/
and a paper about it at
http://www.lambdacs.com/debugger/AADEBUG_Mar_03.pdf

Another more recent paper on the topic is
http://scg.unibe.ch/archive/papers/Lien08bBackInTimeDebugging.pdf

I haven't read either of these papers myself, but maybe they'll give
you some ideas.

Vil.
--
http://mail.python.org/mailman/listinfo/python-list

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads