This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author tim.peters
Recipients ian_osh, tim.peters
Date 2020-07-24.20:48:32
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1595623712.38.0.650342956328.issue41389@roundup.psfhosted.org>
In-reply-to
Content
I see no evidence of a bug here. To the contrary, the output proves that __del__ methods are getting called all along. And if garbage weren't being collected, after allocating a million objects each with its own megabyte string object, memory use at the end would be a terabyte, not a comparatively measly ;-) gigabyte

Note that Python's cyclic gc is NOT asynchronous. It only runs when you call it directly, or when an internal count of allocations exceeds an internal count of deallocations. When your loop ends, your output shows that 940 A and B objects remain to be collected, spread across some number of the gc's "generations". That's where your gigabyte lives (about a thousand A objects each with its own megabyte of string data). It will remain in use until gc is forced to run again. But 99.9% of the A objects have already been collected.
History
Date User Action Args
2020-07-24 20:48:32tim.peterssetrecipients: + tim.peters, ian_osh
2020-07-24 20:48:32tim.peterssetmessageid: <1595623712.38.0.650342956328.issue41389@roundup.psfhosted.org>
2020-07-24 20:48:32tim.peterslinkissue41389 messages
2020-07-24 20:48:32tim.peterscreate