Posted by Jaromir Matas on Apr 19, 2021; 1:08pm
URL: https://forum.world.st/stepping-over-non-local-return-in-a-protected-block-tp5128777p5128855.html

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