Objects on running thread are not deleted

[efimov-mikhail]

Bug report

Bug description:

import time, _thread

class F:
    def __del__(self):
        print("del")

def waitingThread():
    lock.release()
    f = F()
    time.sleep(10)

lock = _thread.allocate_lock()
lock.acquire()
_thread.start_new_thread(waitingThread, ())
lock.acquire()

I anticipate "del" text to be printed.
But it seems that f is not decrefed to zero, and __del__ method is not called.

FWIW, this code snippet is a variant of test.test_threading.ThreadTests.test_finalize_running_thread.

CPython versions tested on:

CPython main branch, 3.11.2

Operating systems tested on:

linux

[efimov-mikhail]

On public API:

import time, threading

class F:
    def __del__(self):
        print("del")

def waitingThread():
    f = F()
    time.sleep(10)

th = threading.Thread(target=waitingThread, daemon=True)
th.start()

Maybe this is desirable for daemon threads to not desctruct linked objects, IDK.

[ZeroIntensity]

I think this is somewhat known/intended. During finalization, daemon threads hang, so they don't get a chance to free their memory. Usually the process is about to exit so we don't bother with freeing things, but I could see this being an issue with subinterpreters.

A potential fix would be to call PyThreadState_Clear/PyThreadState_Delete before hanging the thread, but that might be problematic as it could make thread state attachment much more expensive in some cases.

[colesbury]

See the note in object.__del__(self):

It is not guaranteed that del() methods are called for objects that still exist when the interpreter exits. weakref.finalize provides a straightforward way to register a cleanup function to be called when an object is garbage collected.

[ZeroIntensity]

Ah, wait, ignore my previous comment. I misunderstood how we finalize remaining thread states -- the thread states are indeed forced to clean up, just not until the very end of finalization where Python code can't run anymore. The objects are physically deleted, it's just that their destructor doesn't run as @colesbury said. There doesn't seem to be any issue here.

[efimov-mikhail]

Ok, if this is intentional behavior, I have no questions. Thanks for the explanation!