[issue38106] [2.7] Race in PyThread_release_lock on macOS - can lead to memory corruption and deadlock

Kirill Smelkov added the comment: :) Yes and no. PyPy did not make a new release with the fix yet. -- ___ Python tracker <https://bugs.python.org/issue38

[issue38106] [2.7] Race in PyThread_release_lock on macOS - can lead to memory corruption and deadlock

Kirill Smelkov added the comment: Victor, thanks for merging. > I'm surprised that we still find new bugs in this code which is supposed to > be battle tested! Maybe recent Darwin changed made the bug more likely. As discussed above (https://bugs.python.org/issue38106#msg351917,

[issue26360] Deadlock in thread.join on Python 2.7/macOS

Kirill Smelkov added the comment: > > Maybe issue38106 related. > > That looks plausible, but unfortunately I'm still able to reproduce the hang > with your PR (commit 9b135c02aa1edab4c99c915c43cd62d988f1f9c1, macOS 10.14.6). Thanks for feedback. Then hereby bug is pr

[issue38106] Race in PyThread_release_lock - can lead to memory corruption and deadlock

Kirill Smelkov added the comment: Ok, I did https://github.com/python/cpython/pull/16047. -- ___ Python tracker <https://bugs.python.org/issue38106> ___ ___

[issue38106] Race in PyThread_release_lock - can lead to memory corruption and deadlock

Change by Kirill Smelkov : -- keywords: +patch pull_requests: +15669 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16047 ___ Python tracker <https://bugs.python.org/issu

[issue38106] Race in PyThread_release_lock - can lead to memory corruption and deadlock

Kirill Smelkov added the comment: I agree it seems like a design mistake. Not only it leads to suboptimal implementations, but what is more important, it throws misuse risks onto the user. -- ___ Python tracker <https://bugs.python.org/issue38

[issue26360] Deadlock in thread.join on Python 2.7/Mac OS X 10.9, 10.10

Kirill Smelkov added the comment: Maybe issue38106 related. -- nosy: +navytux ___ Python tracker <https://bugs.python.org/issue26360> ___ ___ Python-bugs-list m

[issue8410] Fix emulated lock to be 'fair'

Kirill Smelkov added the comment: Thanks for feedback. -- ___ Python tracker <https://bugs.python.org/issue8410> ___ ___ Python-bugs-list mailing list Unsub

[issue38106] Race in PyThread_release_lock - can lead to memory corruption and deadlock

Kirill Smelkov added the comment: And it is indeed better to always do pthread_cond_signal() from under mutex. Many pthread libraries delay the signalling to associated mutex unlock, so there should be no performance penalty here and the correctness is much more easier to reason about

[issue38106] Race in PyThread_release_lock - can lead to memory corruption and deadlock

Kirill Smelkov added the comment: Thanks for feedback. Yes, since for Python-level lock, PyThread_release_lock() is called with GIL held: https://github.com/python/cpython/blob/v2.7.16-129-g58d61efd4cd/Modules/threadmodule.c#L69-L82 the GIL effectively serves as the synchronization device

[issue8410] Fix emulated lock to be 'fair'

Kirill Smelkov added the comment: At least condition variable signalling has to be moved to be done under mutex for correctness: https://bugs.python.org/issue38106. -- nosy: +navytux ___ Python tracker <https://bugs.python.org/issue8

[issue433625] bug in PyThread_release_lock()

Kirill Smelkov added the comment: I still believe there is a race here and it can lead to MEMORY CORRUPTION and DEADLOCK: https://bugs.python.org/issue38106. -- nosy: +navytux ___ Python tracker <https://bugs.python.org/issue433

[issue38106] Race in PyThread_release_lock - can lead to MEMORY CORRUPTION and DEADLOCK

New submission from Kirill Smelkov : Hello up there. I believe I've discovered a race in PyThread_release_lock on Python2.7 that, on systems where POSIX semaphores are not available and Python locks are implemented with mutexes and condition variables, can lead to MEMORY CORRUPTION and DEADLOCK