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

Christoph Thiede christoph.thiede at student.hpi.uni-potsdam.de
Wed Oct 28 12:50:44 UTC 2020


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?
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



--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html


More information about the Squeak-dev mailing list