| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
| |
(#122190)
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.
|
| |
|
|
|
| |
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.
|
| |
|
|
| |
The functions look thread-safe and I haven't seen any warnings issued
when running the tests locally.
|
| |
|
|
| |
The only remaining race in dictobject.c was in _PyDict_CheckConsistency
when the dictionary has shared keys.
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
| |
(GH-120490)
|
| |
|
|
| |
Fix a race in `PyMember_GetOne` and `PyMember_SetOne` for `Py_T_OBJECT_EX`.
These functions implement `__slots__` accesses for Python objects.
|
| | |
|
| |
|
| |
Add TSAN suppression for set_default_allocator_unlocked
|
| |
|
| |
Make PyType_HasFeature atomic
|
| |
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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`.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
The `sem_clockwait` function is not currently instrumented, which leads
to false positives.
|
| | |
|
| |
|
|
| |
The GIL may be disabled concurrently with this call so we need to use a
relaxed atomic load.
|
| |
|
| |
Seen in CI occasionally when running `test_weakref`.
|
| |
|
|
| |
Due to a limitation in TSAN, all reads from `PyThreadState.state` must be
atomic to avoid reported races.
|
| |
|
|
|
| |
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`.
|
| |
|
| |
Fix itertools.count in free-threading mode
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
`_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.
|
| |
|
| |
Use relaxed loads/stores when reading/writing to this field.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
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.
|
| |
|
|
| |
This is only used by the specializing interpreter and the tier 2
optimizer, both of which are disabled in free-threaded builds.
|
| | |
|
| | |
|
| |
|
|
| |
Fixup TSAN errors for dict
|
| | |
|
| |
|
|
| |
The load of `ob_ref_local races with stores. Using a relaxed load is
sufficient; stores to the field are relaxed.
|
| |
|
| |
Use relaxed load to check if dictkeys are immortal
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
