[squeak-dev] A bug in #releaseCriticalSection: preventing correct unwind (in rare situations)

Marcel Taeumel marcel.taeumel at hpi.de
Thu Jul 7 12:59:40 UTC 2022


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/41544144/attachment.html>


More information about the Squeak-dev mailing list