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