<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Thanks Jaromir,</p>
<p><br>
</p>
<p>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 ... :-)</p>
<p><br>
</p>
<p>Best,</p>
<p>Christoph</p>
<div id="x_Signature">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="x_divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">
<div class="x__rp_U4 x_ms-font-weight-regular x_ms-font-color-neutralDark x_rpHighlightAllClass x_rpHighlightBodyClass" id="x_Item.MessageUniqueBody" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif,serif,EmojiFont">
<div dir="ltr">
<div id="x_divtagdefaultwrapper"><font face="Calibri,Helvetica,sans-serif,EmojiFont,Apple Color Emoji,Segoe UI Emoji,NotoColorEmoji,Segoe UI Symbol,Android Emoji,EmojiSymbols">
<div id="x_Signature">
<div style="margin:0px"><font style="font-family:Calibri,Arial,Helvetica,sans-serif,serif,EmojiFont">
<div><font size="3" color="black"><span style="font-size:12pt"><a href="http://www.hpi.de/" target="_blank" rel="noopener noreferrer" id="LPNoLP"><font size="2"><span id="LPlnk909538"><font color="#757B80"></font></span></font></a></span></font></div>
</font></div>
</div>
</font></div>
</div>
</div>
</div>
</div>
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Jaromir Matas <m@jaromir.net><br>
<b>Gesendet:</b> Montag, 19. April 2021 15:08:55<br>
<b>An:</b> squeak-dev@lists.squeakfoundation.org<br>
<b>Betreff:</b> Re: [squeak-dev] stepping over non local return in a protected block</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Hi Christoph,<br>
<br>
<br>
Christoph Thiede wrote<br>
> But the fact that the guard contexts are not removed again should not lead<br>
> to a cannot return situation. Instead, I would rather have expected that<br>
> the UI process would be terminated. But somehow, the termination in<br>
> BlockClosure >> #newProcess fails. I observed that primitive 88 in Process<br>
> >> #suspend fails so the execution continues right from the bottom context<br>
> of the process. I'm not sure why primitiveSuspend fails here. Might this<br>
> be related to the changes in termination logic? Jaromir? :-)<br>
<br>
In my opinion the problem is that when the Debugger invokes #stepOver over a<br>
non-local return, it invokes #evaluate:onBehalfOf: down the chain of sends<br>
to execute the non-local return and that's where the problem lies:<br>
#evaluate:onBehalfOf: incorrectly executes the non-local return on the wrong<br>
stack - the debugger process uses its own stack to have<br>
#evaluate:onBehalfOf: executed the non-local return ([^2]) which fails to<br>
find its home context which is indeed on a different stack (original<br>
process's stack). The cannot return is just a consequence of the failure to<br>
find the home context...<br>
<br>
At least this is my working hypothesis :)<br>
<br>
Compared to #evaluate:onBehalfOf:, the #runUntilErrorOrReturnFrom: method<br>
itself jumps right into the debugged process's stack - which results in<br>
flawless execution of the non-local return! It finds it's home context and<br>
jumps into it and continues execution.<br>
<br>
I, however, haven't explored the behavior of the combination of<br>
#evaluate:onBehalfOf: and #runUntilErrorOrReturnFrom: :o As I said my<br>
Debugger knowledge is still negligible, unfortunately.<br>
<br>
Prior to your change from active to genuine process the `[^2] ensure: []`<br>
example caused the infinite debugger loop... after that it only causes the<br>
cannot return error. So I guess it's unlikely the change in #terminate<br>
somehow affected the bug's behavior; the bug was there before and behaves<br>
similarly.<br>
<br>
The change in #teminate only eliminated the use #evaluate:onBehalfOf: in the<br>
termination procedure...<br>
<br>
I'm looking at it from a different angle now, I'll keep you posted...<br>
Thanks,<br>
best,<br>
<br>
<br>
<br>
<br>
-----<br>
^[^ Jaromir<br>
--<br>
Sent from: <a href="http://forum.world.st/Squeak-Dev-f45488.html">http://forum.world.st/Squeak-Dev-f45488.html</a><br>
<br>
</div>
</span></font>
</body>
</html>