Description

pablogsal

opened on Aug 20, 2025

Issue body actions

Setting and getting the current ref tracer should be done while all the threads are stopped to avoid races. This is because users cannot ever safely free the old ref tracer's user data in a free threaded build, because is not possible to ever be sure that no other thread is in the middle of calling the ref tracer. Without synchronizing across threads there, one thread can still be trying to use the old tracer while another thinks it has been successfully uninstalled and safe to clean up

Linked PRs

• gh-137992: Stop the world when calling PyRefTracer_SetTracer #137994
• gh-137992: fix PyRefTracer_SetTracer to start world before returning  #138925

Activity

1. pablogsal

   added

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   3.13only security fixesonly security fixes

   topic-free-threading

   3.14bugs and security fixesbugs and security fixes

   on Aug 20, 2025
2. pablogsal

   added 2 commits that reference this issue on Aug 20, 2025

   pythongh-137992: Stop the world when calling PyRefTracer_SetTracer an…

   962bc0d

   pythongh-137992: Stop the world when calling PyRefTracer_SetTracer an…

   572411b
3. pablogsal

   added 3 commits that reference this issue on Sep 15, 2025

   Merge branch 'main' into pythongh-137992

   5664fd5

   gh-137992: Stop the world when calling PyRefTracer_SetTracer (#137994)

   c5180d7

   gh-137992: fix `PyRefTracer_SetTracer` to start world before returning (

   5c4bb9b
4. kumaraditya303

   closed this as completedon Sep 15, 2025
5. kumaraditya303

   added

   3.15bugs and security fixesbugs and security fixes

   and removed

   3.13only security fixesonly security fixes

   3.14bugs and security fixesbugs and security fixes

   on Sep 15, 2025
6. colesbury

   marked tracemalloc aborts when run from threads in no-gil #126315 as a duplicate of this issue on Nov 25, 2025
7. devdanzin

   unmarked tracemalloc aborts when run from threads in no-gil #126315 as a duplicate of this issue on Apr 15, 2026
8. devdanzin commented on Apr 15, 2026

   

   devdanzin

   on Apr 15, 2026

   Member

   More actions

   Quick question on backport intent: is the fix for this issue (gh-137994, and the follow-up gh-138925) intentionally main-only, or was a 3.14 backport just missed?

   Checking locally, both fix commits are reachable from main but not from the 3.14 branch:

   $ git branch --contains c5180d74e19   # gh-137994
     main
   $ git branch --contains 5c4bb9b7f6a   # gh-138925
     main
   

   On a 3.14 free-threaded debug + TSan build from early April 2026, PyRefTracer_SetTracer still has the pre-fix code:

   int PyRefTracer_SetTracer(PyRefTracer tracer, void *data) {
       _Py_AssertHoldsTstate();
       _PyRuntime.ref_tracer.tracer_func = tracer;
       _PyRuntime.ref_tracer.tracer_data = data;
       return 0;
   }

   and I can reproduce the original race from pure-stdlib Python (via tracemalloc.start() / tracemalloc.stop() while other threads allocate Python objects. _PyTraceMalloc_Start calls PyRefTracer_SetTracer, and every allocation invokes _PyReftracerTrack via new_reference). The same reproducer on a 3.15 main build is clean for this specific race, as expected.

   I came across this while running ThreadSanitizer on the guppy3 C extension, which installs and uninstalls its own ref tracer through PyRefTracer_SetTracer. The TSan warnings pointed at exactly the writes this patch protects, and I was able to isolate the race to pure stdlib without involving the extension.

   Totally understand if the answer is "3.14 is in security-only mode for this class of bug" or "the fix has subtle interactions we don't want to backport". Just wanted to check whether this was a deliberate decision or an oversight, in case it's the latter and a simple cherry-pick would help.

   ---

   Investigation and comment draft done with assistance from Claude Code, reviewed by a human.

Issue actions