Here is a second approach to fix the bug:


Process >> basicEvaluate: aBlock onBehalfOf: aProcess

| range savedVariables |
"range accesses everything after myList, e.g. threadId, effectiveProcess, name, island, env"
range := 5 to: Process instSize.
savedVariables := range collect: [:i| self instVarAt: i].
range do:
[:i| self instVarAt: i put: (aProcess instVarAt: i)].
effectiveProcess := aProcess.
^aBlock ensure:
["write back any assigned-to variables."
range do:
[:i| | v |
((v := self instVarAt: i) ~~ (aProcess instVarAt: i)
and: [v notNil]) ifTrue:
[aProcess instVarAt: i put: v]].
"restore old values"
range with: savedVariables do:
[:i :var| self instVarAt: i put: var]]

Process >> evaluate: aBlock onBehalfOf: aProcess
"Evaluate aBlock setting effectiveProcess to aProcess, and all other variables other than
the scheduling ones to those of aProcess.  Used in the execution simulation machinery
to ensure that Processor activeProcess evaluates correctly when debugging."

^ self
basicEvaluate: [aBlock
on: UnhandledError
do: [:ex |
self
basicEvaluate: [ex pass]
onBehalfOf: self]]
onBehalfOf: aProcess

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

To summarize, in #evaluate:onBehalfOf:, catch UnhandledErrors that are raised by aBlock and handle them on behalf of the original process. Maybe this would be a less invasive solution. Unfortunately, for reasons I did not yet figure out, this fixes all recursions listed in my latest post, with exception of Generator>>#nextPut:.

Best,
Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von tim Rowledge <tim at rowledge.org>
Gesendet: Dienstag, 28. Januar 2020 21:24 Uhr
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?))

>
> <fix-infinite-debuggers.2.cs>


Interesting. I filed that into a 19230 image (because that's what I had running) and tried my PlumbingDemo-crash again. It *doesn't( make stepping over the break work but it *does* result in a clean new debugger on the debugger that shows the problem I reported with the Context>jump leading to Context>at: 0. More interestingly the #at: 0 problem is now a simple case of doPop->pop->at:->errorSubscriptBounds with no strange #at: failing to notice index = 0.

I'm still baffled by how this can be breaking so strangely; it's just the usual 'self break' at the beginning of a perfectly ordinary looking method. Maybe it's the whole Morphic drawing method thing. And clearly there is some interaction with Eliot's work on process-faithful debugging.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful random insult:- One clown short of a circus.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200201/18a7e082/attachment-0001.html>