Debugger woes

Anthony Hannan ajh18 at cornell.edu
Tue Sep 2 06:58:51 UTC 2003


"Andreas Raab" <andreas.raab at gmx.de> wrote:
> > All the simulation behavior is in the 'changing suspended state'
> > protocol in Process.  So it is not too intertwinded.  Maybe 
> > it would be better to rename this 'simulation'.
> 
> Okay, I went over the methods and yes, it all looks as if they are used
> exclusively for simulation. All but one (very important) place -
> Process>>terminate invokes (if not the active process) the full simulation
> machinery via popTo: and friends. Can you explain why process termination
> has to go to this particular length? It looks as if you've got something
> specific in mind here but I don't see why we can't terminate the process
> "just the way it used to be" (that is: merely unwind the stack and be done
> with it).

I wanted to execute the unwind blocks in the context of the terminating
process and not the calling process.  Meaning if an unwind block raises
an exception, an exception handler in the terminating process will
handle it and not one in the calling process.  To do this I resume
(simulate) the terminating process but with a "bottomContext return" on
top causing the process to return to its bottom context while executing
unwind blocks on the way.

> > You have to modify the process because you are executing it 
> > even if its one step at a time.
> 
> That is almost (but not quite) correct. You only have to modify the process
> "inplace" if you wish to preserve a strict mapping between the "debugged"
> and the "real" process state (e.g., so that the process' suspended context
> maps exactly to the simulation state). I am not sure if that is either
> required or a Good Idea; as a matter of fact I am more leaning towards that
> it's not a good idea (considering some of the mechanisms required to debug
> something like Croquet's real-time scheduled processes).

It sounds like you want to keep a copy of the process (a continuation),
so you can abort what you did in the debugger.

> One of the changes that I've thought about for the purpose of debugging
> processes was to essentially associate a debugger with a process (via
> instVar) which - if present - handles attempts to do things with the process
> where potentially "incorrect" state (such as suspendedContext) is involved.
> The places which come to mind immediately are (for example) #suspend,
> #resume, and #terminate but there may be others. In the context of a debug
> session, we may indeed forward these requests to the debugger which could
> then provide us with the "right" means for handling them.

Are you talking about locking the process while mainpulating it, so it
is not inadvertently resumed before you are done manipulating it?

> I think what's really important here is to distinguish between the state a
> process is in when it is debugged (simulated) and when it is run by the VM.
> Since we can't really simulate the process (as it isn't active) it seems as
> if some clear distinction between debugging and running might be rather
> helpful.

I still don't see the difference between running and simulating.  You
are
going through the same execution steps, its just one is written in
Smalltalk and the other is written in Slang.  In Smalltalk you have one
Smalltalk process executing another Smalltalk process.  In Slang (VM),
you have a native process executing a Smalltalk process.  Maybe you want
to keep an original copy (a continuation) around.

> The old (pre 3.6) debugger had that distinction.

Maybe the old debugger didn't change the suspendedContext but it did
change the temps in the contexts you stepped through, effectively
changing the process.

> - it might get "out of sync" at times but for enabling certain kinds of debug facilities that's
> exactly what you need.

I not sure what facilities you mean.

> > To speed things up the 
> > simulate code in #complete: hands off execution to the VM until
> > a specified context completes than the simulation takes over again
> > (old #quickStep).
> 
> where exactly does this happen? I have done some pretty weird things
> with contexts myself but _that_ method is really beyound me ;-)

Yes, sorry context swapping (#jump) is a little perverse plus it wasn't
commented well enough.  Attached is a new version that does normal
process resuming instead of context swapping and is better commented.

The gist of it is to resume the suspended process but have it suspend
itself when a certain context is popped.  This is done by inserting an
#ensure context under the certain context with an unwind block that will
re-suspend the current process when reached.  Again, we want to run in
the suspended process so the correct exception handlers are active.

> If you can give me a bit of help regarding
> #popTo: it would be greatly appreciated.

#popTo: calls #complete: for the same reason: we want the suspended
process's exception handlers active when unwinding.

> > Let me know if you want to make this change to #complete:.  Or if you
> > want me too.

The version attached addresses the changes I was referring to except
for adding a don't-quickStep preference which you said you don't want.

Cheers,
Anthony
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RewriteProcComplete-ajh.cs
Type: application/octet-stream
Size: 3110 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030902/f366b60e/RewriteProcComplete-ajh.obj


More information about the Squeak-dev mailing list