[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
|