[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
Sun Nov 15 21:10:13 UTC 2020


Hi all, hi Eliot,

sorry for double-posting on purpose, but this issue and my thoughts on it
have become so complicated that I needed to separate two different subtopics
from each other:


I just identified another limitation in the process-faithful debugging
model, it cannot be applied nestable:

Consider the following expression:
Processor activeProcess environmentAt: #foo put: 42.
Processor halt activeProcess environmentAt: #foo.

This snippet returns 42 independently of whether you click Proceed in the
Halt Debugger or instead click Debug and then step over the second
#activeProcess send. However, you cannot select the Over or Through button
in the debugger and debug its action on a third process - if you try to do
so, an environmentKeyNotFound error will be raised eventually from the DoIt.

The reason for this is that the effectiveProcess approach is not nestable. I
find this quite a pity in a self-supporting system ...

Here is a very small patch that would eliminate this restriction:

 Processor >> effectiveProcess
     "effectiveProcess is a mechanism to allow process-faithful debugging.
The debugger executes code on behalf of processes, so unless some effort is
made the identity of Processor activeProcess is not correctly maintained
when debugging code. The debugger uses evaluate:onBehalfOf: to assign the
debugged process as the effectiveProcess of the process executing the code,
preserving process identity."

+	^effectiveProcess ifNil: [self] ifNotNil: [:process | process
effectiveProcess]
-	^effectiveProcess ifNil: [self]

Would it be possible to apply this change or are there any good arguments
against it? :-) If it would be possible, I would be glad to upload the patch
to the inbox, and I also have prepared some tests for it.

I'm proposing this change in the same thread as the #basicActiveProcess
discussion because if we decide to make process-faithful debugging nestable
(please! :D), #basicActiveProcess (probably #executingProcess would be a
better name for it ...) as some kind of reciprocal operation for
#effectiveProcess should be nestable in this case, too.


Also, here are two more related questions for you (sorry for the walls of
text! ;-)):

1.) Could you maybe explain the motivation for Kernel-eem.894/Kernel-eem.895
to me? Why is it necessary to modify the non-effective process? In a current
Trunk image, ProcessorScheduler does never expose activeProcess itself
(without wrapping it with an #effectiveProcess send). Are there any other
references that need to be taken into account? I reverted to eem 9/7/2009
11:10 of #evaluate:onBehalfOf: and the environments example from above is
still working. I have read [this
thread](http://forum.world.st/Process-specific-state-difficult-to-debug-td4802422.html#a4802507)
but I cannot reproduce your error and also System-eem.699 seems to be the
wrong reference, at least I don't see how MessageTally is related to
process-faithful debugging.

2.) This might be or might not be a question of coding styles, but when I
browse the senders of #evaluate:onBehalfOf:, there are some methods that
eventually make nested calls to #evaluate:onBehalfOf:, for instance,
#popTo:/#return:value:/#activateReturn:value:. I assume this was not an
intentional decision but kept for simplicity? Should we maybe eliminate
these redundant nestings (and maybe speed up some things) by introducing a
few basic selectors, or would this not be worth the time?


I am looking forward to your help! :-)

Best,
Christoph



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


More information about the Squeak-dev mailing list