The adaptive counter doesn't do anything currently in the free-threaded
build and TSan reports a data race due to concurrent modifications to
the counter.
(cherry picked from commit 2b163aa9e7)
Co-authored-by: Sam Gross <colesbury@gmail.com>
In the free-threaded build, we need to lock pending->mutex when clearing
the handling_thread in order not to race with a concurrent
make_pending_calls in the same interpreter.
(cherry picked from commit c557ae97d6)
Co-authored-by: Sam Gross <colesbury@gmail.com>
The functions look thread-safe and I haven't seen any warnings issued
when running the tests locally.
(cherry picked from commit 7641743d48)
Co-authored-by: Sam Gross <colesbury@gmail.com>
The only remaining race in dictobject.c was in _PyDict_CheckConsistency
when the dictionary has shared keys.
(cherry picked from commit 3ec719fabf)
Co-authored-by: Sam Gross <colesbury@gmail.com>
The `used` field must be written using atomic stores because `set_len`
and iterators may access the field concurrently without holding the
per-object lock.
(cherry picked from commit 9c08f40a61)
Co-authored-by: Sam Gross <colesbury@gmail.com>
Refactor the fast Unicode hash check into `_PyObject_HashFast` and use relaxed
atomic loads in the free-threaded build.
After this change, the TSAN doesn't report data races for this method.
(cherry picked from commit 294e724964)
Co-authored-by: AN Long <aisk@users.noreply.github.com>
Fix a race in `PyMember_GetOne` and `PyMember_SetOne` for `Py_T_OBJECT_EX`.
These functions implement `__slots__` accesses for Python objects.
(cherry picked from commit 362cd2680b)
Co-authored-by: Daniele Parmeggiani <8658291+dpdani@users.noreply.github.com>
gh-117657: Add TSAN suppression for set_default_allocator_unlocked (GH-120500)
Add TSAN suppression for set_default_allocator_unlocked
(cherry picked from commit 2bacc2343c)
Co-authored-by: AN Long <aisk@users.noreply.github.com>
gh-117657: Make PyType_HasFeature atomic (GH-120210)
Make PyType_HasFeature atomic
(cherry picked from commit eebae2c460)
Co-authored-by: Ken Jin <kenjin@python.org>
gh-117657: Make Py_TYPE and Py_SET_TYPE thread safe (GH-120165)
(cherry picked from commit e16aed63f6)
Co-authored-by: Ken Jin <kenjin@python.org>
Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
Co-authored-by: Nadeshiko Manju <me@manjusaka.me>
This adds a `_PyRecursiveMutex` type based on `PyMutex` and uses that
for the import lock. This fixes some data races in the free-threaded
build and generally simplifies the import lock code.
(cherry picked from commit e21057b999)
Co-authored-by: Sam Gross <colesbury@gmail.com>
The `_PyThreadState_Bind()` function is called before the first
`PyEval_AcquireThread()` so it's not synchronized with the stop the
world GC. We had a race where `gc_visit_heaps()` might visit a thread's
heap while it's being initialized.
Use a simple atomic int to avoid visiting heaps for threads that are not
yet fully initialized (i.e., before `tstate_mimalloc_bind()` is called).
The race was reproducible by running:
`python Lib/test/test_importlib/partial/pool_in_threads.py`.
(cherry picked from commit e69d068ad0)
Co-authored-by: Sam Gross <colesbury@gmail.com>
The free-threaded build currently immortalizes objects that use deferred
reference counting (see gh-117783). This typically happens once the
first non-main thread is created, but the behavior can be suppressed for
tests, in subinterpreters, or during a compile() call.
This fixes a race condition involving the tracking of whether the
behavior is suppressed.
(cherry picked from commit 47fb4327b5)
The `sem_clockwait` function is not currently instrumented, which leads
to false positives.
(cherry picked from commit 41c1cefbae)
Co-authored-by: Sam Gross <colesbury@gmail.com>
gh-117657: Fix data races report by TSAN unicode-hash (gh-119907)
(cherry picked from commit 0594a27e5f)
Co-authored-by: Donghee Na <donghee.na@python.org>
The GIL may be disabled concurrently with this call so we need to use a
relaxed atomic load.
(cherry picked from commit f3b89a63cb)
Co-authored-by: Sam Gross <colesbury@gmail.com>
Due to a limitation in TSAN, all reads from `PyThreadState.state` must be
atomic to avoid reported races.
(cherry picked from commit 90ec19fd33)
Co-authored-by: Sam Gross <colesbury@gmail.com>
Only call `gc_restore_tid()` from stop-the-world contexts.
`worklist_pop()` can be called while other threads are running, so use a
relaxed atomic to modify `ob_tid`.
(cherry picked from commit 60593b2052)
Co-authored-by: Sam Gross <colesbury@gmail.com>
This ensures we don't lose races that occur in subprocesses or
interleave races from workers running in parallel.
Log files are collected and packaged into a zipfile that can be
downloaded from the "Artifacts" section of the workflow run.
(cherry picked from commit b88889e9ff)
Co-authored-by: mpage <mpage@meta.com>
`_Py_qsbr_unregister` is called when the PyThreadState is already
detached, so the access to `tstate->qsbr` isn't safe without locking the
shared mutex. Grab the `struct _qsbr_shared` from the interpreter
instead.
(cherry picked from commit 33d20199af)
Co-authored-by: Alex Turner <alexturner@meta.com>
Using `race:` filters out warnings if the function appears anywhere in
the stack trace. This can hide a lot of unrelated warnings, especially
for a function like `_PyEval_EvalFrameDefault`, which is somewhere on
the stack more often than not.
Change all free-threaded suppressions to `race_top:`, which only matches
the top frame, and add any new suppressions this exposes.
(cherry picked from commit 98ff3f65c0)
Co-authored-by: Brett Simmers <swtaarrs@users.noreply.github.com>
Use relaxed atomics when reading / writing to the field. There are still a
few places in the GC where we do not use atomics. Those should be safe as
the world is stopped.
(cherry picked from commit cb6f75a32c)
Co-authored-by: mpage <mpage@meta.com>
Quiet erroneous TSAN reports of data races in `_PySeqLock`
TSAN reports a couple of data races between the compare/exchange in
`_PySeqLock_LockWrite` and the non-atomic loads in `_PySeqLock_{Abandon,Unlock}Write`.
This is another instance of TSAN incorrectly modeling failed compare/exchange
as a write instead of a load.
Fix data races in the method cache in free-threaded builds
These are technically data races, but I think they're benign (to
the extent that that is actually possible). We update cache entries
non-atomically but read them atomically from another thread, and there's
nothing that establishes a happens-before relationship between the
reads and writes that I can see.
Additionally, reduce the iterations for a few weakref tests that would
otherwise take a prohibitively long amount of time (> 1 hour) when TSAN
is enabled and the GIL is disabled.
Miss Islington (bot)
Sam Gross
mpage
Alex Turner
Dino Viehland
Donghee Na