[issue42263] Removing thread reference in thread results in leaked reference

Jason R. Coombs added the comment: Yes, I agree it's a duplicate of issue37788. And yes, it does still leak if the list is never created or if the target is a no-op. -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> fix for bpo-36402

[issue42263] Removing thread reference in thread results in leaked reference

Martin Panter added the comment: Maybe this is related to (or duplicate of) Issue 37788? Python 3.7 has a regression where threads that are never joined cause leaks; previous code was written assuming you didn't need to join threads. Do you still see the leak even if you don't clear the

[issue42263] Removing thread reference in thread results in leaked reference

Change by Martin Panter : -- nosy: +martin.panter ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42263] Removing thread reference in thread results in leaked reference

Jason R. Coombs added the comment: I don't think it's a race condition for two reasons: adding a `time.sleep(1)` after `.start` still raises errors, and in issue37193, there were 10 threads created, with at least 9 of those reaching termination before the test ended, yet it showed 10

[issue42263] Removing thread reference in thread results in leaked reference

Ronald Oussoren added the comment: Could this be a race condition? The thread that's created in the test is not waited on (join), it may or may not have exited by the time the test function returns. -- nosy: +ronaldoussoren ___ Python tracker

[issue42263] Removing thread reference in thread results in leaked reference

New submission from Jason R. Coombs : In issue37193, I'd worked on an implementation in which a thread reference would be removed as the thread was closing, but this led to a memory leak caught by the buildbots (https://bugs.python.org/issue37193#msg380172). As I tracked down the issue in