Thanks Jaromir,


this exception makes very much sense. So to fix this bug, we "only" need to fix #runUntilErrorOrReturnFrom: for stack-manipulating code. I'll need to clean up my inbox a bit to find out whether there have been any recent posts on this issue ... :-)


Best,

Christoph

<http://www.hpi.de/>
________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Jaromir Matas <m at jaromir.net>
Gesendet: Montag, 19. April 2021 15:08:55
An: squeak-dev at lists.squeakfoundation.org
Betreff: Re: [squeak-dev] stepping over non local return in a protected block

Hi Christoph,


Christoph Thiede wrote
> But the fact that the guard contexts are not removed again should not lead
> to a cannot return situation. Instead, I would rather have expected that
> the UI process would be terminated. But somehow, the termination in
> BlockClosure >> #newProcess fails. I observed that primitive 88 in Process
> >> #suspend fails so the execution continues right from the bottom context
> of the process. I'm not sure why primitiveSuspend fails here. Might this
> be related to the changes in termination logic? Jaromir? :-)

In my opinion the problem is that when the Debugger invokes #stepOver over a
non-local return, it invokes #evaluate:onBehalfOf: down the chain of sends
to execute the non-local return and that's where the problem lies:
#evaluate:onBehalfOf: incorrectly executes the non-local return on the wrong
stack - the debugger process uses its own stack to have
#evaluate:onBehalfOf: executed the non-local return ([^2]) which fails to
find its home context which is indeed on a different stack (original
process's stack). The cannot return is just a consequence of the failure to
find the home context...

At least this is my working hypothesis :)

Compared to #evaluate:onBehalfOf:, the #runUntilErrorOrReturnFrom: method
itself jumps right into the debugged process's stack - which results in
flawless execution of the non-local return! It finds it's home context and
jumps into it and continues execution.

I, however, haven't explored the behavior of the combination of
#evaluate:onBehalfOf: and #runUntilErrorOrReturnFrom: :o As I said my
Debugger knowledge is still negligible, unfortunately.

Prior to your change from active to genuine process the `[^2] ensure: []`
example caused the infinite debugger loop... after that it only causes the
cannot return error. So I guess it's unlikely the change in #terminate
somehow affected the bug's behavior; the bug was there before and behaves
similarly.

The change in #teminate only eliminated the use #evaluate:onBehalfOf: in the
termination procedure...

I'm looking at it from a different angle now, I'll keep you posted...
Thanks,
best,




-----
^[^ Jaromir
--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210419/e933a6d5/attachment.html>