[squeak-dev] Fixing the infinite debugger chains? (was: Code simulation error (was Re: I broke the debugger?))

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Wed Oct 28 15:40:53 UTC 2020


Hi Eliot,


thanks for your reply!

<http://www.hpi.de/>

> Therefore, an error within the evaluate block of Process >> #evaluate:onBehalfOf: could be caught within Process >> #evaluate:onBehalfOf: but delivered outside.  One could experiment with adding an exception handler around the evaluation block that would copy the stack of the exception, terminate the block, and then open a debugger on the copy of the stack once the effectiveProcess has been restored.

This sounds pretty much like what I proposed here: http://forum.world.st/I-broke-the-debugger-tp5110752p5111016.html
This solution would also have the advantage of a lower footprint than any #basicActiveProcess solution.
How would you think about it? :-)

Best,
Christoph
________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Eliot Miranda <eliot.miranda at gmail.com>
Gesendet: Mittwoch, 28. Oktober 2020 14:43:51
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Fixing the infinite debugger chains? (was: Code simulation error (was Re: I broke the debugger?))

Hi all,

> On Oct 28, 2020, at 5:50 AM, Christoph Thiede <christoph.thiede at student.hpi.uni-potsdam.de> wrote:
>
> Hi all! :-)
>
> After a lot of time, I would like to give this issue another push. These
> bugs are really serious and we should finally fix them.
>
> Short summary for everyone who would not like to re-read the whole thread:
> /
> Over the last months, several issues have been reported about infinite
> chains of debuggers popping up in your image and, most of the time,
> eventually making it unusable. Some months ago, I traced these issues down
> to several simulation errors that occurred while pressing the Over button in
> the debugger. The simulation errors can be fixed separately, but the
> debugger chains are caused by a second phenomenon which I could break down
> in the following snippet:
>
>    Processor activeProcess
>        evaluate: [self error: #first. self inform: #second]
>        onBehalfOf: [] newProcess
>
>    You would expect to see first a debugger window for the #error, and
> second, after you resume this error, a dialog window for the #inform:.
> However, surprisingly, both windows appear at the same time. The opening
> debugger does not suspend the process correctly.
> /
>
>
> I also had a talk about it with Marcel and Patrick and we ended up with the
> finding that the semantics of Process >> #evaluate:onBehalfOf: are not 100%
> clear at the moment. Its method comment states:
>
>    "Evaluate aBlock setting effectiveProcess to aProcess, and all other
> variables other than the scheduling ones to those of aProcess."
>
> However, the situation is unclear when an exception is raised from aBlock.
> Should it be handled still on behalf of the behalfOf process or rather on
> the original receiver process instead?

Conceptually Process >> #evaluate:onBehalfOf: is a private method if the debugger, which exists only to ensure that while simulating code on behalf of done process being debugged, the right process is found by the simulated code even though another process is actually executing the code.

Therefore the block being evaluated within Process >> #evaluate:onBehalfOf: is always evaluating some simulation on behalf of the debugger.  Therefore, *any* error which occurs during the block is not an error in the process being debugged (that error delivery should be simulated, and delivered within the process being debugged), but an error in the simulation, and should stop the simulation.

Therefore, an error within the evaluate block of Process >> #evaluate:onBehalfOf: could be caught within Process >> #evaluate:onBehalfOf: but delivered outside.  One could experiment with adding an exception handler around the evaluation block that would copy the stack of the exception, terminate the block, and then open a debugger on the copy of the stack once the effectiveProcess has been restored.

[P.S. I think the right way to implement this is to use Context>>cut: to snip the section of the stack containing the simulation error and stitch this back in after the evaluate block, but I *think* I am seeing bugs in the context-to-stack mapping machinery in the VM which is causing the stitching back of the stack to fail, which is why I’m trying (successfully does far) to simulate the simulator.  So hopefully in a few days the stitching approach will be viable, but did the moment the stack copying approach will work, even though it introduces unnecessary overhead.]

I hope this helps, and I hope I’m understanding the issue correctly.  If I’m not I thank you for your patience :-).

> At the moment, the former is the case, and this leads to the problem that
> the behalfOf process is debugged (i.e. interrupted) when an error is raised
> from aBlock while the - technically actually causing - receiver process
> keeps running, eventually ignoring the just-raised exception. See
> StandardToolSet class >> #handleError: for the place where "Processor
> activeProcess" is determined for debugging, which is redirected to the
> onBehalf process during the execution of aBlock.
> At this place, we actually would like to see something like this:
>
>    thisContext process
>        debug: anError signalerContext
>        title: anError description
>
> Which, however, is not possible because a stack frame cannot know its
> containing process.
> So in my first changeset (fix-infinite-debuggers.2.cs below), I had proposed
> to rewrite that method like this:
>
>    Processor basicActiveProcess
>        debug: anError signalerContext
>        title: anError description
>
> where basicActiveProcess would return the "true" active process neglecting
> the onBehalfOf redirection.
> However, *could there be any situation where you would like to respect the
> process redirection indeed in #handleError:?* (highlighting this as the open
> key question of this thread)
> We did not find a plausible example, the only case I could imagine is the
> following situation (which, admittedly, is not an every-day use case):
>
>    Debug the expression "self halt", step down until in StandardToolSet
> class>>handleError:, step into #activeProcess and then step over repeatedly
> until #debug:title: is sent.
>    In Trunk, this opens a second debugger on the same process. When using
> #basicActiveProcess, however, the first debugger stops working (dead
> process).
>
>
> So, your comments and thoughts are important: How would you think about the
> proposed #basicActiveProcess solution? Do you see any scenario where the
> onBehalfOf redirection needs to be perpetuated in ToolSet >> #handleError:?
> Or would you prefer another approach to fix the problem?
> Looking forward to an interesting discussion! :-)
>
> Best,
> Christoph

Eliot
_,,,^..^,,,_ (phone)

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


More information about the Squeak-dev mailing list