[New-bugs-announce] [issue13697] python RLock implementation unsafe with signals

Robert Collins report at bugs.python.org
Mon Jan 2 22:13:13 CET 2012

New submission from Robert Collins <robertc at robertcollins.net>:

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 (https://bugs.launchpad.net/launchpad/+bug/861742) 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).

components: Library (Lib)
files: hang.py
messages: 150477
nosy: rbcollins
priority: normal
severity: normal
status: open
title: python RLock implementation unsafe with signals
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file24126/hang.py

Python tracker <report at bugs.python.org>

More information about the New-bugs-announce mailing list