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

Marcel Taeumel marcel.taeumel at hpi.de
Tue Mar 16 08:14:18 UTC 2021


Hi Jaromir.

> How can I convince you?


Well, I understand the issue that you described. However, I think it is very bad style to return from within an ensure-block. That's why I would like to set the urgency for this to "rather low". :-)

The idiom for using #ensure: in the return-expression is this:

^ aBlock ensure: ensureBlock
^ [ self doTrickyStuff ] ensure: [ self cleanUp ]


That is, you should only use *inner* returns to get out early. And then, the ensure will clean up after you.

If you really would want to "ensure" a certain return value, you could do it like this:

| result |
[ self doTrickyStuff ] ensure: [ result := 42 ].
^ result

But why using #ensure: at all for such a case? If you think that exceptions might happen, you would have to wrap it this way:

| result |
result := 42.
[ self doTrickyStuff ] on: KnownError do: [ :ex | "Ignore." ].
^ result

Well, doesn't make much sense to me. :-) You clean up resources (i.e. state) via #ensure: when facing exceptions. You do not manage control flow through it. The exception handlers #on:do: are for that.

Do not put a return "^" into an ensure block.

Best,
Marcel

Am 15.03.2021 21:54:47 schrieb Jaromir Matas <m at jaromir.net>:
Hi Marcel,

>> In this discussion, you should always specify whether "responds to"
>> involves a sender within a simulated or genuine "context". ;-) I am still
>> not convinced that this is an actual problem.

Sorry for confusing you, this all new to me :)

How can I convince you? I debug quite naively, no fancy stuff. I'll try
again to show the exact steps replicating the issue using Christoph's
example:

0. downloaded the latest trunk image
Squeak6.0alpha-20304-64bit-202003021730-Windows with Kernel-mt.1381
1. open Process Browser with auto-update on
2. open an explorer window on the current UI process to watch it
3. do-it `[self error: 'e1'] ensure: [^2]` in a Workspace

Now three things happened, as expected (screenshot 1):
a) an Error debugger window popped up
a) the UI process has become suspended
b) a new UI has been created

4. open an explorer window on the new UI process to watch it
5. Abandon the Error window

And now a couple of highly surprising things happened (screenshot 2):
d) Error window disapeared - that's still expected but
e) the new UI process (88230) disappeared from the Process Browser - NOT
expected
AND became the genuineProcess - expected
AND it responds true to isTerminated sent to self in its Explorer window
- NOT expected
f) the old UI process (48259) became the current UI process - NOT expected
AND became the effectiveProcess - NOT expected
AND responds true to isActiveProcess sent to self in its Explorer
window - confusing

At this point however the genuine process is indeed not terminated but
executing. It is not shown on the Process Browser however because it filters
out terminated processes. You can verify this by changing first line in
isTerminated, for a moment, to:

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

And now everything runs as usual as if nothing happened except the really
executing process is hidden from your view and the formerly debugged process
acts as the active process but is not really executing (see screenshot 3
with the invisible process 88230 shown).

6. now I reverted isTerminated back to original and did Christoph's do-it
`self error`

And the rest went as Christoph described; I'd just like to point out the
hidden process 88230 now reappears as the current UI process and correctly
responds true to isActiveProcess e.g. in the Explorer window. In case you
hit Proceed on the Unwind error window the two UI processes above will start
alternating because they are now both runnable in the priority 40 queue.

I find this course of events very unexpected; trying to follow using the
standard tools is very confusing - namely the disappearing genuine process.
I know it's due to the bug Christoph discovered and described but the tools
should rather reveal, not hide information vital for understanding what's
happening :)

I apologize for such a long description and sincerely hope I haven't made
any error here to waste your time.

Thanks,

Screenshot1.png
Screenshot2.png
Screenshot3.png



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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210316/4a7f6b1b/attachment.html>


More information about the Squeak-dev mailing list