Repository navigation
Data race: TextIOWrapper.detach() stores self->buffer = NULL non-atomically #154523
Description
Bug report
Bug description:
In the free-threaded build, TextIOWrapper.detach() clears the self->buffer slot with a plain store, while reading tw.buffer goes through a LOAD_ATTR_SLOT specialization that reads the same slot with FT_ATOMIC_LOAD_PTR.
Writer — _io_TextIOWrapper_detach_impl:
Lines 1630 to 1645 in a2a8466
Reader — LOAD_ATTR_SLOT reads the slot atomically:
cpython/Python/generated_cases.c.h
Lines 9493 to 9503 in a2a8466
So tw.buffer racing tw.detach() is a plain-store-vs-atomic-load data race on the buffer slot. detach() should store the slot atomically.
Reproducer:
import io
from threading import Thread
def make():
return io.TextIOWrapper(io.BytesIO(b'x' * 16))
slot = [make()]
def reader():
for _ in range(20000):
try:
_ = slot[0].buffer
except Exception:
pass
def detacher():
for _ in range(20000):
try:
slot[0].detach()
except Exception:
pass
slot[0] = make()
threads = [Thread(target=reader) for _ in range(6)]
threads += [Thread(target=detacher) for _ in range(2)]
for t in threads: t.start()
for t in threads: t.join()TSAN Report:
WARNING: ThreadSanitizer: data race (pid=1522499)
Write of size 8 at 0x7fffd0100110 by thread T7:
#0 _io_TextIOWrapper_detach_impl /cpython/./Modules/_io/textio.c:1642:18
#1 _io_TextIOWrapper_detach /cpython/./Modules/_io/clinic/textio.c.h:793:20
#2 _PyEval_EvalFrameDefault /cpython/Python/generated_cases.c.h:4330:35
Previous atomic read of size 8 at 0x7fffd0100110 by thread T6:
#0 _Py_atomic_load_ptr /cpython/./Include/cpython/pyatomic_gcc.h:300:18
#1 _PyEval_EvalFrameDefault /cpython/Python/generated_cases.c.h:9588:36
#2 _PyEval_EvalFrame /cpython/./Include/internal/pycore_ceval.h:122:16
SUMMARY: ThreadSanitizer: data race /cpython/./Modules/_io/textio.c:1642:18 in _io_TextIOWrapper_detach_impl
==================
CPython versions tested on:
CPython main branch
Operating systems tested on:
macOS, Linux
Activity
devdanzin commented on Jul 23, 2026
Agree this is a genuine C-level data race worth the "store the slot atomically" fix, but as a severity note: it looks value-benign on aligned hardware — I couldn't turn it into a crash.
Tried on a free-threaded debug build and a free-threaded ASan build of main: the reader/detacher race (amplified — readers also touch the returned buffer), and separately concurrent detach() on a shared wrapper (barrier-synchronized, to try for a double-Py_CLEAR/double-DECREF), both run clean across many attempts.
That matches the code: _io_TextIOWrapper_detach_impl is @critical_section (so concurrent detach() can't double-free — the second one gets NULL from buffer_access_safe and raises), and it transfers ownership of the buffer to the caller via return buffer rather than Py_CLEAR-ing it — so the LOAD_ATTR_SLOT reader's atomic-load-plus-try-incref never increfs a freed object. What remains is exactly a plain pointer store (self->buffer = NULL) vs an atomic pointer load on the aligned slot: real UB that TSan correctly flags, but the reader only ever observes the old valid pointer or NULL. So the atomic-store fix is right as UB hygiene; there doesn't appear to be a memory-safety issue behind it.
Checked and drafted with AI assistance (Claude Code), verified by hand on free-threaded debug/ASan builds of main.
kumaraditya303 commented on Jul 30, 2026
The fix should change buffer to be a getset descriptor and use critical section to access it.
gh-154523: Fix data-race in `TextIOWrapper.detach()` (#154565)
pythongh-154523: Fix data-race in `TextIOWrapper.detach()` (python#15…
[3.15] gh-157364: Fix use-after-free in io.TextIOWrapper during reent…
[3.14] gh-157364: Fix use-after-free in io.TextIOWrapper during reent…