The TSAN nogil build fails tests for me on themain branch as well. So I'm not sure this change is the cause of the test failure. I get these failures on main branch:

8 tests failed:    test_capi.test_mem test_capi.test_pyatomic test_functools    test_importlib test_queue test_signal test_threading_local    test_threadsignals

I'm a little unclear on the change here. My understanding is that we don't want the interned strings on legacy subinterpreters to be tracked on those interpreter's refs. It seems to me like the change in this PR has stopped fixing that for each interpreter, which would put us back to where we were before. What am I missing?

A problem with trace refs occurs both with immortal and mortal interned strings. The previous fix,_Py_NormalizeImmortalReference, only handled the immortal case. The new test I added triggers both cases and if you remove either fix, it crashes in_Py_ForgetReference.

I was trying to trigger a third case, where objects other than interned strings are shared and are created in one interpreter and deallocated in a different one. That would cause_Py_ForgetReference to fail too. However, I can't seem to make it happen, I think because of them_copy dict stored in runtime structure. So, maybe we are safe from that one.

Other than that, I have one small suggestion.

Fixed as you suggest.

Maybe I overdid it with the comments, some are a bit redundant. Another idea I was toying with is to make this tracerefs cleanup logic active only if non-isolated interpreters are being used. You need a flag on the main interp to know if sub-interpreters have been used that share its interned string dict. Possible patch here:

https://gist.github.com/nascheme/2243a137b9f9aa4639590231e3b8e004

It adds a new set of internal flags to the interp state so I think it can't be backported since it changes the ABI. I tried usingfeature_flags but I think that's not the correct place to put the flag. It's not a public API.

I wonder: for interpreters thatuse_main_obmalloc, would it make sense to also use the main ref chain?

I wonder: for interpreters thatuse_main_obmalloc, would it make sense to also use the main ref chain?

I think that could work and would simplify the code. The major impact would be thatgc.getobjects() in one of those interpreters (could be main) would return objects for all sub-interpreters with that flag. Maybe that's an improvement actually. I'm not sure what people would expect. Ask@pablogsal maybe since he uses the TraceRefs build?

I think that the assumption so far of that call is to get all objects in existence. I don't think semantics have been defined after subinterpeters were introduced so we have some wiggle room here

Here's a PR that shares the main refchain with all legacy interpreters:#125709. FWIW, they all used to share it when it was stored in global variables.

Closing sinceGH-125709 fixes the same issue and seems a better approach.