This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rbcollins
Recipients rbcollins
Date 2012-01-02.21:13:11
SpamBayes Score 4.26875e-12
Marked as misclassified No
Message-id <>
This affects the python implementation of RLock only.

If a signal occurs during RLock.acquire() or release() and then operates on the same lock to acquire() or release() it, process hangs or assertions can be triggered.

The attached test script demonstrates the issue on Python 2.6 and 3.2, and code inspection suggests this is still valid for 2.7 and 3.4.

To use it, run the script and then 'kill -SIGUSR2' the process id it prints out. Keep sending SIGUSR2 until you get bored or:
 - a traceback occurs
 - the process stops printing out '.'s

We found this debugging application server hangs during log rotation ( where if the thread that the signal is received in was about to log a message the deadlock case would crop up from time to time. Of course, this wasn't ever safe code, and we're changing it (to have the signal handler merely set a integer flag that the logging handler can consult without locking).

However, I wanted to raise this upstream, and I note per issue #3618 that the 3.x IO module apparently includes a minimal version of the Python RLock implementation (or just uses RLock itself). Either way this bug probably exists for applications simply doing IO, either when there is no C RLock implementation available, or all the time (depending on exactly what the IO module is doing nowadays).
Date User Action Args
2012-01-02 21:13:13rbcollinssetrecipients: + rbcollins
2012-01-02 21:13:13rbcollinssetmessageid: <>
2012-01-02 21:13:12rbcollinslinkissue13697 messages
2012-01-02 21:13:12rbcollinscreate