Hi Marcel,

The issue is fixed for #terminate by using #suspendAndReleaseCriticalSection and the corresponding tests are #testMutexInCriticalEnsureArgument and #testSemaInCriticalEnsureArgument; however, the issue still remains in #releaseCriticalSection: which is being used by #terminateAggressively which means if you run the same example but Abandon the debugger instead of terminating it the Mutex's owner won't get cleared which is the bug.

To summarize the root cause: the code in #releaseCriticalSection: tries to deal with three possible implementations of #critical (see https://forum.world.st/Solving-termination-of-critical-sections-in-the-context-of-priority-inversion-was-SemaphoreTest-fail-tp5082184.html); eventually version V1 was adopted but the code dealing with V2 remained and left a hole causing V1 fail in the case showed by the example (below).

The fix was that I used only the relevant code from #releaseCriticalSection: in #suspendAndReleaseCriticalSection being used by #terminate.

The question remains what to do with #terminateAggressively (Abandon); I've just tried to simply replace #releaseCriticalSection: with #suspendAndReleaseCriticalSection but that doesn't seem to help and my original fix doesn't work for #terminateAggressively either which means there may be something else at play here.

Thanks,
Jaromir


From: Marcel Taeumel<mailto:marcel.taeumel at hpi.de>
Sent: Thursday, July 7, 2022 15:00
To: squeak-dev<mailto:squeak-dev at lists.squeakfoundation.org>
Subject: Re: [squeak-dev] A bug in #releaseCriticalSection: preventing correct unwind (in rare situations)

Hi Jaromir --

What is the current status of this? :-)

Best,
Marcel

Am 21.12.2021 18:14:21 schrieb mail at jaromir.net <mail at jaromir.net>:
Hi Eliot, all,

There's a bug, or rather an omission, in #releaseCriticalSection: causing the following examples unwind incorrectly:

Mutex new inspect critical: [self halt]

If you run the example in a workspace, a debugger and an inspector opens - please watch Mutex's 'owner' variable; then step into a few times to get right before sending #primitiveExitCriticalSection and terminate the debugger (in the newest images please use debugger's window menu -> terminate process); and observe the owner won't get cleared and will remain blocking the Mutex. Same behavior for Semaphores:

Semaphore forMutualExclusion inspect critical: [self halt]

Again, watch Semaphore's excessSignals variable in the Inspector, step into a few times until you stand before sending #signal - and terminate the debugged process (from the debuggers menu or from the Process Browser if you like) - the Semaphore won't recharge excessSignals back to 1.

The root cause is #releaseCriticalSection: doesn't account for terminating in this particular position of the computation. It can be fixed e.g. by adding an additional condition ('progressedIntoEnsure') - try the examples with the enclosed changeset; both Mutexes and Semaphores work ok now.

Best,

~~~
^[^ Jaromir

Sent from Squeak Inbox Talk
["Process-releaseCriticalSection.st"]

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