gh-117657: Add TSAN suppressions for the free-threaded build - #117736
Conversation
Sorry, something went wrong.
Add TSAN suppressions for existing races in the free-threaded build.
colesbury
left a comment
There was a problem hiding this comment.
Great!
Now that we have a list we can split up the work on fixing the data races.
Sorry, something went wrong.
Yep! I'll create issues and link them to #117657. |
Sorry, something went wrong.
corona10
left a comment
There was a problem hiding this comment.
Well LGTM.
Sorry, something went wrong.
|
|
||
| ## Free-threaded suppressions | ||
|
|
||
| race:_add_to_weak_set |
There was a problem hiding this comment.
Are there GH issues open for all these suppressions?
Sorry, something went wrong.
There was a problem hiding this comment.
Not yet, working on it :) I want to provide a bit more context (i.e. sample stacktraces + repro instructions) rather than just cutting issues without context.
Sorry, something went wrong.
There was a problem hiding this comment.
I'd like to start with a simple list in an omnibus issue like #117657 so that there's a single place that people can go look to track who is working on what races.
I expect many of the races to have simple fixes, but we can break off the more complex races into their own issues as needed.
The work of collecting stacktraces and repros is work that can be split up once this PR is landed and we have a way of coordinating the work.
Sorry, something went wrong.
There was a problem hiding this comment.
Sounds good. I threw together a quick script to massage the TSAN output from the tests into an index that we can use to look for stacktraces and tests that should reproduce the races.
Sorry, something went wrong.
…ython#117736) 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.
Add TSAN suppressions for existing races in the free-threaded build.
Additionally, skip a few tests that take a prohibitively long amount of time (> 1 hour) when TSAN is enabled and the GIL is disabled. I'm not sure why these are so much slower with TSAN (> 1 hour) vs without it (~1 minute). perf shows that all of the time is being spent in inclusively in GC in both configurations. When TSAN is enabled ~all of the exclusive cycles are in TSAN code (e.g __tsan_read8, __tsan_read1, etc.).
I cherry-picked this on top of the nogil-integration branch and verified that the free-threading TSAN tests pass locally and in CI.