Hi again Christoph,

> I'm not absolutely sure to which posts you are referring with in your message (footnotes missing), but I will assume that you are referring the non local return issue [1]. 

Yes, sorry for the confusion. I'm now confused again how to refer to a thread in the pipermail archives - they do not link threads across calendar month boundaries, or do they?

> tl;dr for this changeset: If we accept Kernel-jar.1413, the need for a detection of harmless jumps seems uncertain so far. I think the changeset runs pretty smoothly and I see no reason why we should not move it into the Trunk eventually. Further objections still desired! :-)

Thanks again for your comments in [1]; I've amended Kernel-jar.1413 as per your request and replaced it by Kernel-jar.1421 [3]. We can continue discussing this particular issue in [1] / [2].

As for the general issue discussed in this thread I very much like your idea quoted below and I hope I will find some time to explore it further. It sounds like a serious project for long winter nights :)

> [...] instead of only uninstalling the guard contexts to halt the simulation, reinstall the guard contexts again for the new context after switching to it, and then continue the simulation, all of which would happen without the client of the simulator (the user) being affected. When handling the ContextSwitch, we could then identify harmless direct return jumps by inspecting the context stack and resuming the simulator if the context switch was considered harmless.

> [...] I'm wondering whether such a "harmless detection" would be applicable to some other situations, too. Were you having some more concrete situations in mind when you had this idea?

Good question! I'll have to check my notes but first I'll try to respond to our other open discussions :)

Thanks, 

Best,

Jaromir

[1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-August/216214.html

[2] http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-November/216971.html

[3] http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-November/216972.html


On 2021-08-22T20:00:39+02:00, christoph.thiede at student.hpi.uni-potsdam.de wrote:

> Hi Jaromir,
> 
> I'm not absolutely sure to which posts you are referring with in your message (footnotes missing), but I will assume that you are referring the non local return issue [1]. As already mentioned there, my concern with your proposed fix for this is that the execution engine (#aboutToReturn:through:/#resume:through: etc.) and the debugger/simulator (#runUntilErrorOrReturnFrom:) belong to two different roles that should not be intermixed more often than necessary; but let's discuss this in [1]. :-)
> 
> The false positives you are mentioning are a problem indeed, but your idea to recognize harmless jumps is ingenious, and I think that this should be possible - not straightforward, but possible. Currently, #informDebuggerAboutContextSwitchTo: only works as a kind of sheet anchor - halt the simulator before we could loose it. But we could also go one step further and replace the fake UnhandledError in this hook by a particular ContextSwitch exception. #runUntilErrorOrReturnFrom: could handle this exception and instead of only uninstalling the guard contexts to halt the simulation, reinstall the guard contexts again for the new context after switching to it, and then continue the simulation, all of which would happen without the client of the simulator (the user) being affected. When handling the ContextSwitch, we could then identify harmless direct return jumps by inspecting the context stack and resuming the simulator if the context switch was considered harmless.
> 
> So technically, I guess it would be possible, but it would also be a rather complex implementation, though. Maybe it would not be worth the effort just for the issue with non-local returns (for which you found a significantly shorter hack), so I'm wondering whether such a "harmless detection" would be applicable to some other situations, too. Were you having some more concrete situations in mind when you had this idea? For #jump and #swapSender:, I cannot imagine such a situation, because as opposed to #resume:through:, they do not only perform a simple return but replace the entire stack, so without further indication I would consider a halt mandatory.
> 
> tl;dr for this changeset: If we accept Kernel-jar.1413, the need for a detection of harmless jumps seems uncertain so far. I think the changeset runs pretty smoothly and I see no reason why we should not move it into the Trunk eventually. Further objections still desired! :-)
> 
> Best,
> Christoph
> 
> [1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-August/216214.html
> 
> ---
> Sent from Squeak Inbox Talk
> 
> On 2021-05-29T16:03:40-05:00, m at jaromir.net wrote:
> 
> > Hi Christoph,
> > 
> > 
> > Christoph Thiede wrote
> > > Hi all, hi Jaromir,
> > > 
> > > with regard to the bug mentioned in [1], I have updated the changeset from
> > > above: runUntilErrorOrReturnFrom.cs
> > > <http://forum.world.st/file/t372205/runUntilErrorOrReturnFrom.cs> 
> > > 
> > > Basically, I inserted a send to #informDebuggerAboutContextSwitchTo: in
> > > the
> > > loop body of Context >> #resume:through: as well.
> > > 
> > > I could not find any regressions from the previous changeset, but since
> > > this
> > > is a very low-level method, any crash tests will be appreciated. I believe
> > > that in the past a similar approach has crashed my image, but I could not
> > > reproduce this any longer today ...
> > > 
> > > I am also - still :-) - very excited to hear your feedback and thoughts on
> > > the general approach. In my message from above, I have highlighted two
> > > bold
> > > questions, it would be great if some of our Kernel experts could find a
> > > few
> > > minutes for them. Nicolas? Eliot? Jaromir? :-)
> > > 
> > > Best,
> > > Christoph
> > > 
> > > [1]
> > > http://forum.world.st/stepping-over-non-local-return-in-a-protected-block-td5128777.html
> > > 
> > > 
> > > 
> > > -----
> > > Carpe Squeak!
> > > --
> > > Sent from: http://forum.world.st/Squeak-Dev-f45488.html
> > 
> > Unless I'm mistaken I believe the issue from [1] is just a bug described in
> > [2], not a general issue. The implementation simply forgot to consider the
> > inserted guard contexts and can be fixed fully (I hope) by amending
> > #resume:through: and #return:from: as proposed in [1]. In such case
> > including #resume:through: in your changeset is not necessary.
> > 
> > You're addressing here a fundamental problem stemming from manipulating
> > contexts by #jump, #swapSender (and who knows what else) breaking the linear
> > order of context chains. On one hand it's amazing you can catch and deal
> > with those situations, on the other hand there are "false positives", I mean
> > catching harmless jumps and stopping the debugger unexpectedly e.g. during
> > debugging regular #terminate using "well behaving" jumps :) 
> > 
> > I'm wondering: would it be possible to somehow recognize "harmless" or "well
> > known" jumps so that the changeset can let them be and only interrupt
> > "unknown" patterns or those somehow recognized as dangerous? 
> > 
> > This is a very interesting problem and I look forward to your further
> > discoveries :)
> > 
> > best regards,
> > 
> > 
> > 
> > -----
> > ^[^ 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/20210822/d1e05667/attachment.html>
> 
>