-
Notifications
You must be signed in to change notification settings - Fork 201
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
[BUG]: Data race reported by TSAN with free-threading #740
Comments
Hi @vfdev-5, I tried your example and also ran the test suite with TSAN. I at first got a huge amount of warnings about races in Compiling Python with A question to @colesbury: I suspect that TSAN gets confused by the non-standard Python mutex unless both Python and the extension are compiled with TSAN enabled. Is this possible? |
@colesbury: While debugging, I also noticed the following: We currently immortalize type objects with the following assignments
However, these values don't all stay frozen. In one debugging session, I noticed an immortal type object with an This is on Python 3.14 master. |
I suspect this isn't going to work unless the Python interpreter is built with I also suspect that PyMutex would probably benefit from tsan annotations: |
Yeah, in general you want your whole application compiled with tsan or it will miss synchronizations in the non-instrumented portion. (I don't think the mutex-specific warnings are particularly useful, which is why we don't use them.) I'm not sure what would cause |
@colesbury : I tracked it to frame #1: 0x00000001003350bc python3` _PyType_MergeThreadLocalRefcounts(tstate=0x000000010611c000) + 340 at typeid.c:159
frame #2: 0x0000000100335130 python3` _PyType_FinalizeThreadLocalRefcounts(tstate=0x000000010611c000) + 36 at typeid.c:169
frame #3: 0x0000000100308444 python3` PyThreadState_Clear(tstate=0x000000010611c000) + 2044 at pystate.c:1748
frame #4: 0x00000001003c68dc python3` thread_run(boot_raw=0x0000000104c011a0) + 468
frame #5: 0x000000010032df80 python3` pythread_wrapper(arg=0x0000000104a00050) + 68 at thread_pthread.h:243
frame #6: 0x0000000100bc45b0 libclang_rt.tsan_osx_dynamic.dylib` __tsan_thread_start_func + 144
frame #7: 0x000000018525bfa8 libsystem_pthread.dylib` _pthread_start + 148 |
Thanks a lot @wjakob for checking this and sorry for the noise, definitely, compiling python3.13t with TSAN removes a lot of reported data races in the repro code and my other tests. |
@vfdev-5 Can the issue be closed? Or do you still see races that could be a problem in nanobind? |
Ah, that makes sense. That's confusing, but I don't think it really matters. Once |
@wjakob yes, we can close this issue. No problems from nanobind side. |
Problem description
Hi @wjakob , I still see some data race reports by TSAN sometimes mentioning
keep_alive
ornb_type_put_common
orinst_new_ext
. For example, a report I could get usingmaster
(c1bab7e):I could create a reproducible example below:
C++ extension
CMakeLists.txt:
Can you please confirm the issue and maybe hint what could be the issue with the nanobind or the usage, thanks!
Reproducible example code
The text was updated successfully, but these errors were encountered: