Paul McDonough wrote:

> The Squeak debugger, afaik, is a "simulating debugger"
> a la Visual Works.  That means, when you run through
> the debugger, you're actually doing most of the vm
> work (identifying which objects get what messages,
> etc.) in Smalltalk, and only invoking the vm when it
> comes down to #perform:.  That means that the
> simulation semantics and the vm's semantics need to
> match, and (apparently) they don't.

I'll offer what little I have to share about this bug, if someone can make
use of it:  I also encounter this problem frequently, and the other day I
decided to look into it, briefly. The problem in that case was an attempted
access to a position on the stack that didn't exist. I thought it seemed
very odd, almost impossible (obviously not), but I guess now that this meant
that the simulated stack must have gone out of sync. I don't know what that
means.

Also, these walkbacks seem to occur when stepping (cmd-t) in the debugger,
usually when stepping over a message that is rather big, ie. executes a
large number of bytecodes/message sends.

I don't know if this gives anyone else a clue about the problem.

A question: why can't the stepping use the ordinary vm? Alt: why does it use
simulated execution? Reason for question: as it is, some almost irrelevant
messages take ages to step over, eg. Transcript show: since it refreshes the
whole screen (in simulated mode), and frequently cause the bug we are
discussing, meaning that you'll have to start over debugging.

Henrik