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! :-)


[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@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