Thanks to visit codestin.com
Credit goes to github.com

Skip to content

BUG: data race in from_dlpack method under free-threading #28881

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.

Sign up for GitHub

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

Jump to bottom
Closed
vfdev-5 opened this issue May 1, 2025 · 2 comments · Fixed by #28883
Closed

BUG: data race in from_dlpack method under free-threading #28881

vfdev-5 opened this issue May 1, 2025 · 2 comments · Fixed by #28883
Labels
00 - Bug 39 - free-threading PRs and issues related to support for free-threading CPython (a.k.a. no-GIL, PEP 703)

Comments

@vfdev-5
Copy link

vfdev-5 commented May 1, 2025

Describe the issue:

There is time of check to time of use race in from_dlpack method seen under free-threading in JAX CI 3.14 FT TSAN:

numpy/numpy/_core/src/multiarray/dlpack.c

Lines 512 to 513 in 99e52b1

if (call_kwnames == NULL) {
call_kwnames = Py_BuildValue("(sss)", "dl_device", "copy", "max_version");

TSAN report:

2025-05-01T05:34:57.9237309Z WARNING: ThreadSanitizer: data race (pid=40474)
2025-05-01T05:34:57.9237908Z   Read of size 8 at 0x7ae1f630d900 by thread T5 (mutexes: read M0):
2025-05-01T05:34:57.9239389Z     #0 from_dlpack /__w/jax/jax/numpy/.mesonpy-rfh9ohv3/../numpy/_core/src/multiarray/dlpack.c:512:9 (_multiarray_umath.cpython-314t-x86_64-linux-gnu.so+0x27bb77) (BuildId: 7329d207c0ff1ee77c70b97b156153450b873370)
2025-05-01T05:34:57.9241678Z     #1 cfunction_vectorcall_FASTCALL_KEYWORDS /__w/jax/jax/cpython/Objects/methodobject.c:470:24 (python3.14+0x29bf58) (BuildId: 3f23fd04b2cf761640aff608738700b3591be0b6)
2025-05-01T05:34:57.9243471Z     #2 _PyObject_VectorcallTstate /__w/jax/jax/cpython/./Include/internal/pycore_call.h:169:11 (python3.14+0x1f19ba) (BuildId: 3f23fd04b2cf761640aff608738700b3591be0b6)
2025-05-01T05:34:57.9244791Z     #3 PyObject_Vectorcall /__w/jax/jax/cpython/Objects/call.c:327:12 (python3.14+0x1f19ba)
2025-05-01T05:34:57.9246353Z     #4 _PyEval_EvalFrameDefault /__w/jax/jax/cpython/Python/generated_cases.c.h:1451:35 (python3.14+0x3fdb5c) (BuildId: 3f23fd04b2cf761640aff608738700b3591be0b6)
2025-05-01T05:34:57.9248016Z     #5 _PyEval_EvalFrame /__w/jax/jax/cpython/./Include/internal/pycore_ceval.h:119:16 (python3.14+0x3f9470) (BuildId: 3f23fd04b2cf761640aff608738700b3591be0b6)
2025-05-01T05:34:57.9249250Z     #6 _PyEval_Vector /__w/jax/jax/cpython/Python/ceval.c:1953:12 (python3.14+0x3f9470)
...
2025-05-01T05:34:57.9485539Z   Previous write of size 8 at 0x7ae1f630d900 by thread T7 (mutexes: read M0):
2025-05-01T05:34:57.9487981Z     #0 from_dlpack /__w/jax/jax/numpy/.mesonpy-rfh9ohv3/../numpy/_core/src/multiarray/dlpack.c:513:22 (_multiarray_umath.cpython-314t-x86_64-linux-gnu.so+0x27bbb6) (BuildId: 7329d207c0ff1ee77c70b97b156153450b873370)
2025-05-01T05:34:57.9489981Z     #1 cfunction_vectorcall_FASTCALL_KEYWORDS /__w/jax/jax/cpython/Objects/methodobject.c:470:24 (python3.14+0x29bf58) (BuildId: 3f23fd04b2cf761640aff608738700b3591be0b6)
2025-05-01T05:34:57.9492133Z     #2 _PyObject_VectorcallTstate /__w/jax/jax/cpython/./Include/internal/pycore_call.h:169:11 (python3.14+0x1f19ba) (BuildId: 3f23fd04b2cf761640aff608738700b3591be0b6)
2025-05-01T05:34:57.9493472Z     #3 PyObject_Vectorcall /__w/jax/jax/cpython/Objects/call.c:327:12 (python3.14+0x1f19ba)

Full report: https://gist.github.com/vfdev-5/61f2a64f103319c0b5d2f850ceee8dcf

Reproduce the code example:

No reproducer yet

Error message:

Full report: https://gist.github.com/vfdev-5/61f2a64f103319c0b5d2f850ceee8dcf

Python and NumPy Versions:

Python 3.14.0a7+ experimental free-threading build (heads/main:4f18916, Apr 27 2025, 05:25:00) [Clang 18.1.3 (1ubuntu1)]
Numpy from source

Runtime Environment:

No response

Context for the issue:

No response
@seberg
Copy link
Member

seberg commented May 1, 2025

Thanks! Harmless as such but we should move them (and maybe their initialization) to the static struct.

@seberg seberg added the 39 - free-threading PRs and issues related to support for free-threading CPython (a.k.a. no-GIL, PEP 703) label May 1, 2025
@ngoldbaum
Copy link
Member

ngoldbaum commented May 1, 2025 •
edited
Loading

I think Sebastian wrote that code last year right around when we introduced the global state struct, so I must have missed this when I did the pass over the code for global state. Easy enough to add it to module init and move the variables to the global state struct.

@ngoldbaum ngoldbaum mentioned this issue May 1, 2025
Merged
@seberg seberg closed this as completed in aa7c4f5 May 2, 2025
charris pushed a commit to charris/numpy that referenced this issue May 2, 2025
@ngoldbaum @charris
MAINT: from_dlpack thread safety fixes (numpy#28883)
770f06d 
Fixes numpy#28881

Moves the global variables defined in from_dlpack to the npy_static_pydata struct and initializes them during module init.
@charris charris mentioned this issue May 2, 2025
Merged
MaanasArora pushed a commit to MaanasArora/numpy that referenced this issue May 8, 2025
@ngoldbaum @MaanasArora
MAINT: from_dlpack thread safety fixes (numpy#28883)
3229cf4 
Fixes numpy#28881

Moves the global variables defined in from_dlpack to the npy_static_pydata struct and initializes them during module init.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
00 - Bug 39 - free-threading PRs and issues related to support for free-threading CPython (a.k.a. no-GIL, PEP 703)
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

MAINT: from_dlpack thread safety fixes ngoldbaum/numpy
3 participants
@seberg @vfdev-5 @ngoldbaum