-
-
Notifications
You must be signed in to change notification settings - Fork 10.9k
BUG: Race on descr->byteorder
under free threading
#28143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
this (kinda silly) diff seems to fix the race: diff --git a/numpy/_core/src/multiarray/ctors.c b/numpy/_core/src/multiarray/ctors.c
index 0723e54f34..8379480389 100644
--- a/numpy/_core/src/multiarray/ctors.c
+++ b/numpy/_core/src/multiarray/ctors.c
@@ -1839,7 +1839,7 @@ PyArray_CheckFromAny_int(PyObject *op, PyArray_Descr *in_descr,
else if (in_descr && !PyArray_ISNBO(in_descr->byteorder)) {
PyArray_DESCR_REPLACE(in_descr);
}
- if (in_descr && in_descr->byteorder != NPY_IGNORE) {
+ if (in_descr && in_descr->byteorder != NPY_IGNORE && in_descr->byteorder != NPY_NATIVE) {
in_descr->byteorder = NPY_NATIVE;
}
} @hawkinsp in your opinion, are changes like above the sort of thing we need to do now or is this the sort of thing it makes sense to write a suppression for? I'll also wait for Sebastian to comment before sending that in since I don't have context if a bigger refactor to avoid writing to effectively global descriptor objects makes sense. |
There's no such thing as a benign race, e.g., see usenix.org/legacy/events/hotpar11/tech/final_files/Boehm.pdf or similar. Even things you think might be safe at a hardware level are extremely difficult to reason about as soon as there is an optimizing compiler involved. So it's probably sensible to fix pretty much anything tsan tells you about. Is this particular bug the most urgent? No. For my own purposes, I have added a tsan suppression and moved on with my life, but I don't want the issue to be forgotten, and hence this bug. But, contrast that with, say, #28048 which I can't work around: I'd rate that sort of issue higher priority. |
For sure, that's definitely high up on my priority queue to fix, and thank you for finding and reporting these issues. |
No arcane knowledge. Just need to look 2 lines up, it should be part of the |
Sorry, nonsense of course... Yeah, I think the fix is good, cose just has a bit weird flow and not sure how well the descr replacement works for user-dtypes but that is a different issue. |
Describe the issue:
When running the following code under TSAN and free-threading, TSAN reports an apparently real race:
Reproduce the code example:
Error message:
Python and NumPy Versions:
Runtime Environment:
[{'numpy_version': '2.3.0.dev0+git20250110.dc78e30',
'python': '3.13.1+ experimental free-threading build '
'(heads/3.13:65da5db28a3, Jan 10 2025, 14:52:18) [Clang 18.1.8 '
'(11)]',
'uname': uname_result(system='Linux', node='redacted', release='6.10.11-redacted-amd64', version='#1 SMP PREEMPT_DYNAMIC Debian 6.10.11-redacted(2024-10-16)', machine='x86_64')},
{'simd_extensions': {'baseline': ['SSE', 'SSE2', 'SSE3'],
'found': ['SSSE3',
'SSE41',
'POPCNT',
'SSE42',
'AVX',
'F16C',
'FMA3',
'AVX2'],
'not_found': ['AVX512F',
'AVX512CD',
'AVX512_KNL',
'AVX512_SKX',
'AVX512_CLX',
'AVX512_CNL',
'AVX512_ICL']}},
{'architecture': 'Zen',
'filepath': '/usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.27.so',
'internal_api': 'openblas',
'num_threads': 128,
'prefix': 'libopenblas',
'threading_layer': 'pthreads',
'user_api': 'blas',
'version': '0.3.27'}]
Context for the issue:
Found when running the JAX test suite with TSAN and free-threading.
The text was updated successfully, but these errors were encountered: