Data race reading `_thread.RLock` recursion count in `repr()` under free-threading
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 77.2k
- Forks
- 35.9k
- PR merge metrics
- PR metrics pending
Description
Bug report
Bug description:
This is a follow-up to #153292 (data race in repr() of _thread.RLock), which was fixed by making rlock_repr read the lock's owner with an atomic load. The fix covered the owner (self->lock.thread) field, but rlock_repr still reads self->lock.level with a plain (non-atomic) load to compute the recursion count:
self->lock.level is written by acquire / release / _acquire_restore, e.g.:
So on a free-threaded build, repr(rlock) concurrent with acquire() or release() is still a data race, now on the level field rather than the owner field the earlier fix addressed.
Reproducer:
import _thread
from threading import Thread, Barrier
shared_rlock = _thread.RLock()
state = (5, _thread.get_ident())
def chain1_thread():
for _ in range(20000):
try:
shared_rlock._acquire_restore(state)
except Exception:
pass
def chain2_thread():
for _ in range(20000):
try:
repr(shared_rlock)
except Exception:
pass
N_C1 = 2
N_C2 = 4
barrier = Barrier(N_C1 + N_C2)
def _c1():
barrier.wait()
chain1_thread()
def _c2():
barrier.wait()
chain2_thread()
threads = [Thread(target=_c1) for _ in range(N_C1)]
threads += [Thread(target=_c2) for _ in range(N_C2)]
for t in threads: t.start()
for t in threads: t.join()
TSAN Report :
==================
WARNING: ThreadSanitizer: data race (pid=655652)
Read of size 8 at 0x7fffb6610540 by thread T6:
#0 rlock_repr /cpython/./Modules/_threadmodule.c:1295:28
#1 PyObject_Repr /cpython/Objects/object.c:784:11
#2 builtin_repr /cpython/Python/bltinmodule.c:2677:12
#3 _PyEval_EvalFrameDefault /cpython/Python/generated_cases.c.h:2712:35
Previous write of size 8 at 0x7fffb6610540 by thread T1:
#0 _thread_RLock__acquire_restore_impl /cpython/./Modules/_threadmodule.c:1210:22
#1 _thread_RLock__acquire_restore /cpython/./Modules/clinic/_threadmodule.c.h:537:20
#2 method_vectorcall_O /cpython/Objects/descrobject.c:476:24
#3 _PyObject_VectorcallTstate /cpython/./Include/internal/pycore_call.h:144:11
#4 PyObject_Vectorcall /cpython/Objects/call.c:327:12
#5 _Py_VectorCallInstrumentation_StackRefSteal /cpython/Python/ceval.c:768:11
#6 _PyEval_EvalFrameDefault /cpython/Python/generated_cases.c.h:1906:35
SUMMARY: ThreadSanitizer: data race /cpython/./Modules/_threadmodule.c:1295:28 in rlock_repr
==================
CPython versions tested on:
CPython main branch
Operating systems tested on:
Linux
Linked PRs
- gh-155381
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in Modules/_threadmodule.c at rlock_repr and the acquire, release, and _acquire_restore implementations described in the report. Run the provided reproducer on a free-threaded build with ThreadSanitizer, then inspect the related tests and verify that concurrent repr() and lock updates no longer report a race.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, python
- Domain
- operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 35/100