[squeak-dev] Simulation discrepancy with #return:

Eliot Miranda eliot.miranda at gmail.com
Tue Mar 13 17:08:12 UTC 2012


Hi Yoshiki,

On Tue, Mar 13, 2012 at 3:27 AM, Yoshiki Ohshima <Yoshiki.Ohshima at acm.org>wrote:

>  Hello,
>
> I noticed that step executing the following code in debugger yields
> different results:
>
> -------------------
> test
>
>        3 < 4 ifTrue: [
>                thisContext return: 42].
>        ^ 666.
> -------------------
>
> In the normal execution, you get 42 as expected, but if you debug it
> and step execute, #return: does not actuall return and you get 666.
>
> It appears that the primitive for #terminateTo: is the culprit...
>

>From what I can see so far it is the return value from
runUntilErrorOrReturnFrom: in complete: when the debugger executes test's
return: call.  i.e. the debugged process is in Foo>>test at pc 43:

37 <22> pushConstant: 3
38 <23> pushConstant: 4
39 <B2> send: <
40 <9B> jumpFalse: 45
41 <89> pushThisContext:
42 <21> pushConstant: 42
43 <E0> send: return:
44 <87> pop
45 <24> pushConstant: 666
46 <7C> returnTop

The stack in the debugger is
Process>>complete:
Process>>completeStep:
Debugger>>doStep



and Process>complete: is

complete: aContext
"Run self until aContext is popped or an unhandled error is raised.  Return
self's new top context, unless an unhandled error was raised then return
the signaler context (rather than open a debugger)."
 | ctxt pair error |
ctxt := suspendedContext.
suspendedContext := nil.  "disable this process while running its stack in
active process below"
pair := ctxt runUntilErrorOrReturnFrom: aContext.
suspendedContext := pair first.
error := pair second.
error ifNotNil: [^ error signalerContext].
^ suspendedContext

where the receiver is the activation of Foo>test, and aContext is the
activation of ContextPart>return: (whose receiver is also the receiver of
complete:, the activation of Foo>test).

In this case runUntilErrorOrReturnFrom: aContext should return the sender
of the activation of Foo>test and the result to be returned (42).  But
instead it answers the activation of Foo>test and nil.  Hence the return in
ContextPart>return: isn't simulated and control passes to the next
statement, ^666.

Once again I'm drawn into the bowels of runUntilErrorOrReturnFrom: :) It is
my nemesis.


> -- Yoshiki
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20120313/b4cb50d4/attachment.htm


More information about the Squeak-dev mailing list