[issue34486] "RuntimeError: release unlocked lock" when starting a thread

Change by Géry : -- nosy: +maggyero ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34486] "RuntimeError: release unlocked lock" when starting a thread

Radek added the comment: Any progress on this topic? I think I've encountered this (or similar) issue: >Traceback (most recent call last): > File "logging/__init__.py", line 1944, in shutdown > File "logging/__init__.py", line 813, in acquire > File "site-packages/utils/signals.py", line

[issue34486] "RuntimeError: release unlocked lock" when starting a thread

Vladimir Matveev added the comment: To bring in analogy: C# has lock statement that allow to run a block of code holding a mutual-exclusion lock on some object. ``` lock(o) { } ``` is compiled as ``` object _lock = o; bool _lockTaken = false; try {

[issue34486] "RuntimeError: release unlocked lock" when starting a thread

Xiang Zhang added the comment: It's not right to replace with statement by manually calling __enter__ and __exit__. If there is any exception after __enter__ and before __exit__, __exit__ method will be skipped. That's not what we want. -- ___

[issue34486] "RuntimeError: release unlocked lock" when starting a thread

hongweipeng added the comment: It seems to me the problem is related to nested `finally` or `with`, which can't handle signals well. class Event: ... def wait(self, timeout=None): self._cond.__enter__() signaled = self._flag if not signaled:

[issue34486] "RuntimeError: release unlocked lock" when starting a thread

Serhiy Storchaka added the comment: This looks similar to to problems with the "with" statement: see issue29988 and issue34067. Except that there is no a "with" statement, and resolving that issues will not solve this issue. -- ___ Python tracker

[issue34486] "RuntimeError: release unlocked lock" when starting a thread

Vladimir Matveev added the comment: I agree. From code in threading.Condition.wait looks like if it is interrupted either after calling _release_save and before entering try block or in finally block before calling _acquire_restore - it will leave the lock in non-acquired state. First

[issue34486] "RuntimeError: release unlocked lock" when starting a thread

Xiang Zhang added the comment: It looks to me pure Python implementation could not handle such cases. Put aside other possible bugs, threading.Condition.wait re-acquire the lock using threading.Condition._acquire_restore which could be interrupted and not able to acquire the lock. So it

[issue34486] "RuntimeError: release unlocked lock" when starting a thread

STINNER Victor added the comment: cond_race.py: simplified example using threading.Lock and threading.Condition: the issue seems to be related to threading.Event which doesn't handle properly signals. -- nosy: +pitrou, serhiy.storchaka Added file:

[issue34486] "RuntimeError: release unlocked lock" when starting a thread

Change by Xiang Zhang : -- nosy: +vstinner, xiang.zhang ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34486] "RuntimeError: release unlocked lock" when starting a thread

Stanisław Skonieczny (Uosiu) added the comment: This scripts runs start_threads.py and send a signal to it. After some number of loops problem can be reproduced. -- Added file: https://bugs.python.org/file47762/test.sh ___ Python tracker

[issue34486] "RuntimeError: release unlocked lock" when starting a thread

New submission from Stanisław Skonieczny (Uosiu) : Sometimes when thread is starting it raises "RuntimeError: release unlocked lock". That is when signal handler is invoked in the same time. Traceback (most recent call last): File "/usr/lib/python3.6/threading.py", line 551, in wait