[squeak-dev] Bug in Process>>#terminate | Returning from unwind contexts

Jaromir Matas m at jaromir.net
Wed Mar 17 20:08:06 UTC 2021


Hi Christoph, Marcel,

Thanks for your feedback!

I'm responding jointly also to your Debugger post... again, apologies for
mixing this up with your genuine process work :) 

> The only exception from this rule appears to occur when the Processor >>
> #evaluate:onBehalfOf: logic does not get unwound correctly so the
> effectiveProcess is not reset, which is a consequence of the bug I
> described
> [here].

Exactly, and that's precisely why I thought it was serious because the bug
made discovering itself so much harder :) This is when one really needs to
be aware of the genuine process and what it is doing.

> [...] after terminating it, the debugged process keeps answering false
> when sent 
> #isTerminated. I think this is also related to the thread you started in
> [3]

Yes, isTerminated (and isSuspended) is fixed by Kernel-jar.1381.mcz in [4].
I'd like to consider it a 'baby step' towards more refined versions in [2]
or [3] you mentioned.

>> What is the expected semantics of the Debugger's Abandon? To quit and do
>> nothing more to the debugged process or continue unwinding?

> I have to agree with Levente here that unwinding should not be skipped
> here
> definitively. 

Oh, absolutely! I managed to throw the baby out with the bathwater
spectacularly :)

> IMHO Debugger >> #abandon should have exactly the same effect as Process
> >> #terminate.

Yes, that's my feeling as well now (although I'm not in a position to give
opinions; I have to go back and study the exceptions again more thoroughly).

The examples I gave (without the non-local return) are not as nasty as your
non-local return example:

The main difference between your non-local example:

[self error: 'e1'] ensure: [^2]

and my one without the non-local return:

[self error: 'e1'] ensure: [self error: 'e2']

is that in your case the ^2 interrupts the orderly unwinding/termination and
the UI process continues as if still in simulation (because of the missed
effective process reset) - until another exception happens *somewhen* in the
future - while in my examples the next exception resetting the
effectiveProcess happens right away in the ensure block, presenting "only"
the Unwind error on the outside.

And on top of that, in your case the image is in such a bad state that
running Process or Semaphore tests even crash the image!

> I wonder whether we can and whether we should find a way to heal
> processes again after a missing reset [of the effectiveProcess].

Very interesting question indeed!

To summarize: the non-local return in the ensure block causes a major
disruption to the flow of control. Indeed the easiest and probably
reasonable solution is to somehow prohibit non-local returns in the ensure
blocks. This scenario, however uncovers a weakness in the #isTerminated,
reporting the currently executing process with effectiveProcess assigned, as
terminated and as a result preventing Process Browser to reveal such a
pathological situation (which is precisely when you need to see it).

Best regards,


PS: For debugging this issue I tweaked my #isTerminated with the first line
conditon reading:

    (self isActiveProcess or: [self effectiveProcess == Processor
activeProcess]) ifTrue: [^ false].

instead of just

    self isActiveProcess ifTrue: [^ false].

to make the genuine process always visible...

[1]
http://forum.world.st/Please-try-out-Fixes-for-debugger-invocation-during-code-simulation-tp5127684p5127807.html
[2] http://forum.world.st/The-Inbox-Kernel-jar-1377-mcz-tp5127438.html
[3]
http://forum.world.st/Refactoring-terminate-to-get-rid-of-cannot-return-errors-etc-td5127732.html
[4] http://forum.world.st/The-Inbox-Kernel-jar-1381-mcz-tp5127665.html




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


More information about the Squeak-dev mailing list