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

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Mon Mar 8 20:08:57 UTC 2021


Hi all,


besides my proposed solution approach for the never-returning sends to Context>>#runUntilErrorReturnFrom: [1], I recently stumbled upon another problem with context manipulation connected to #runUntilErrorReturnFrom:. But I think the cause is a different one and this one brings up a more general design discussion. Let me explain:


The bug itself is pretty simple to reproduce:


1. Do it: [self error] ensure: [^2]

2. Abandon the Error debugger

3. Do it: self error
Expected behavior: A second error debugger is shown
Actual behavior: An unwind error (Unwind error during termination) is shown!

Here's an explanation: If you inspect your UI process after step 2, you will see that two guard contexts (BlockClosure>>on:do: and BlockClosure>>ensure:) are installed right before [] in BlockClosure>>newProcess on the bottom of the sender stack. These contexts have been created by #runUntilErrorOrReturnFrom: as part of the context popping-down performed by Process>>#terminate when abandoning the debugger. Normally, they would have been removed again after unwinding all contexts from the process (and the UI process would have been terminated and been replaced by a new one, see #spawnNewProcessIfThisIsUI:). But because our "ensure: [^2]" has stopped the unwinding, #runUntilErrorOrReturnFrom: and senders are still alive and waiting for the unwinding to complete while the UI process is continuing its everyday world cycles. When the next error is raised at any time later, the UnhandledError guard gets invoked and the signaler context is returned back from Process>>#popTo:, and Process>>#terminate complains that the unwinding has not been successful.

So far about the problem, here are some thoughts and questions:

1. Should it be a legal operation at all to return from an unwind context? (I think it should, because a) it works fine unless Process>>#terminate gets involved, and b) it is a powerful instrument for certain control flows that need to ignore all exceptions.)
(1.1 If you think we should criminalize this operation, should we make efforts to exclude this behavior in #aboutToReturn:through: and other places? I fear this could become quite complex ...)
2. I'm attaching a small changeset to fix this issue by decriminalizing unwind errors and continuing the execution (with the new error) instead of showing an unwind error. It's a small patch of three lines that works surprisingly well for my use case, but I'm not sure whether there could be any other justified reasons for showing an unwind error. Do you know some other relevant reasons for unwinding errors?
3. Also, the solution approach begs a new question to me: Should the #terminate send indeed freeze for potentially hours of image time or millions of bytecodes, or are we required to find another way for this? I hope for the first because I really can't imagine an elegant alternative at the moment.

Looking forward to your thoughts! :-)

CC'ing Jaromir because you're working on the same method at the moment. Afaik you are only reworking the definition of #isTerminated, but probably you can share some interesting insights on this issue, too. :-)


Best,

Christoph


(PS: This message, as my previous one, has become quite long, I know this. General suggestions for reasonable shortening of my texts will be appreciated, I'm always trying to waste as little as possible of your time ... :-))


[1] http://forum.world.st/BUG-REGRESSION-while-debugging-Generator-nextPut-tp5108125p5127567.html



<http://www.hpi.de/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210308/4df2bb07/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unwind-errors.1.cs
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210308/4df2bb07/attachment.ksh>


More information about the Squeak-dev mailing list