GeezerVison

@erlend-aasland Can you confirm that this fixes the issue?

@erlend-aasland Can you confirm that this fixes the issue?

I'll do as soon as I get back on my computer.

UPDATE: This PR does not fix the issue. I've used @pablogsal's reproducer from #26274 (comment). Here's an excerpt of the dump (complete dump attached):

=================================================================
==23898==ERROR: AddressSanitizer: heap-use-after-free on address 0x619000041b48 at pc 0x0001093d7fbe bp 0x7ffee6d13700 sp 0x7ffee6d136f8
READ of size 8 at 0x619000041b48 thread T0
    #0 0x1093d7fbd in subtype_dealloc typeobject.c:1456
    #1 0x10939e680 in _Py_Dealloc object.c:2288
    #2 0x1092d81ac in _Py_DECREF object.h:500
    #3 0x1092d8bdb in _Py_XDECREF object.h:567
    #4 0x1092de271 in list_dealloc listobject.c:342
    #5 0x10939e680 in _Py_Dealloc object.c:2288
    #6 0x10932dafc in _Py_DECREF object.h:500
    #7 0x10933a41b in _Py_XDECREF object.h:567
    #8 0x10933fbfb in dict_dealloc dictobject.c:2068
    #9 0x10939e680 in _Py_Dealloc object.c:2288
    #10 0x1095bfedc in _Py_DECREF object.h:500
    #11 0x1095eb47d in ast_clear Python-ast.c:782
    #12 0x1093f6c51 in subtype_clear typeobject.c:1303
    #13 0x1098c6e70 in delete_garbage gcmodule.c:1017
    #14 0x1098be9af in gc_collect_main gcmodule.c:1300
    #15 0x1098bdf9c in _PyGC_CollectNoFail gcmodule.c:2123
    #16 0x109812be0 in interpreter_clear pystate.c:328
    #17 0x109812e81 in _PyInterpreterState_Clear pystate.c:361
    #18 0x1098017b9 in finalize_interp_clear pylifecycle.c:1634
    #19 0x10980123b in Py_FinalizeEx pylifecycle.c:1812
    #20 0x1098b7143 in Py_RunMain main.c:668
    #21 0x1098b83e4 in pymain_main main.c:696
    #22 0x1098b8694 in Py_BytesMain main.c:720
    #23 0x108eeda71 in main python.c:15
    #24 0x7fff20582f3c in start+0x0 (libdyld.dylib:x86_64+0x15f3c)

0x619000041b48 is located 200 bytes inside of 968-byte region [0x619000041a80,0x619000041e48)
freed by thread T0 here:
    #0 0x10a3ad609 in wrap_free+0xa9 (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x48609)
    #1 0x10939ff08 in _PyMem_RawFree obmalloc.c:127
    #2 0x1093a0ed9 in _PyMem_DebugRawFree obmalloc.c:2540
    #3 0x1093a0fb8 in _PyMem_DebugFree obmalloc.c:2673
    #4 0x1093a1f8f in PyObject_Free obmalloc.c:721
    #5 0x1098c1151 in PyObject_GC_Del gcmodule.c:2345
    #6 0x1093db0e7 in type_dealloc typeobject.c:4041
    #7 0x10939e680 in _Py_Dealloc object.c:2288
    #8 0x1095bfedc in _Py_DECREF object.h:500
    #9 0x1095eb1dd in ast_dealloc Python-ast.c:768
    #10 0x1093d7f83 in subtype_dealloc typeobject.c:1450

dump.txt

@vstinner I don't see how a thread state can remain usable after the interpreter has been cleared.

I just sync'ed with upstream/main to get @vstinner's fix for issue 44184 (GH-26274, 615069e). With that in main and this PR applied, the issue is fixed; thanks! You can disregard my previous comment.

A thread state should remain more or less usable after PyInterpreterState_Clear() is called. I don't think that this PR fix the root issue of https://bugs.python.org/issue44032#msg394104

IMO it would be safer to only release datastack_chunk memory in tstate_delete_common(), rather than in PyThreadState_Clear().

FYI, freeing datastack chunks in tstate_delete_common() iso. deferring PyThreadState_Clear works fine with the reproducer.

🤖 New build scheduled with the buildbot fleet by @markshannon for commit ddad17e 🤖

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.

buildbot/AMD64 RHEL7 Refleaks PR — Build done.
buildbot/AMD64 RHEL8 Refleaks PR — Build done.
buildbot/s390x Fedora Refleaks PR — Build done.

test_asyncio hangs, unrelated error: https://bugs.python.org/issue44112

I'm not worried about asyncio, but test_multiprocessing also fails for one and test_posix for another.

There doesn't seem to a coherent model of how threads and interpreters are related, or what memory belongs to the interpreter or thread.
As a result, cleaning up after a fork is impossible to get right.

There doesn't seem to a coherent model of how threads and interpreters are related, or what memory belongs to the interpreter or thread.
As a result, cleaning up after a fork is impossible to get right.

Sounds like an issue should be opened for this, if there's not already one on bpo.

AMD64 RHEL8 Refleaks PR:

test_posix failed
...
test_posix leaked [1, 0, 0] file descriptors, sum=1

I can be a random error which doesn't fail with re-run in verbose mode, we don't know since the job hangs before test_posix can be re-run.

I'm not worried about asyncio, but test_multiprocessing also fails for one and test_posix for another.

I fail to see the test_multiprocessing error. multiprocessing tests are full of race conditions. Some are legit bugs, some are bugs in the tests. I fixed tons of bugs in multiprocessing and in its test suite last years, but if you search for "multiprocessing" in the bug tracker, you will see a long list of issues open for several weeks/months.

IMO it's perfectly safe to merge this PR. All issues that you saw are very likely known (not regression of your change).

Clearing the current thread state would be another can of worm, but your PR no longer does that ;-)

Ok, I'll merge this then.
It seems to not make things worse, and probably makes them better.

Yeah, it's fine, in the really worst case, we can just revert the change to revisit the options. But again, IMO this function is perfectly safe.