Tim Peters added the comment:
Well, this isn't a help desk ;-) You may want instead to detail your problem
on, say, StackOverflow, or the general Python mailing list.
Please note that I don't know what your "problem" _is_: you haven't said. You
posted some numbers that didn't make sense to
Ian O'Shaughnessy added the comment:
>I don't know of any language that guarantees all garbage will be collected
>"right away". Do you?
I'm not an expert in this domain, so, no. I am however attempting to find a way
to mitigate this issue. Do you have any suggestions how I can avoid these
m
Tim Peters added the comment:
It's impossible for any implementation to know that cyclic trash _is_ trash
without, in some way, traversing the object graph. This is expensive, so
CPython (or any other language) does not incur that expense after every single
decref that leaves a non-zero refc
Ian O'Shaughnessy added the comment:
"Leak" was likely the wrong word.
It does appear problematic though.
The loop is using a fixed number of variables (yes, there are repeated dynamic
allocations, but they fall out of scope with each iteration), only one of these
variables occupies 1MB of r
Tim Peters added the comment:
What makes you think that? Your own output shows that the number of "Active"
objects does NOT monotonically increase across output lines. It goes up
sometimes, and down sometimes. Whether it goes up or down is entirely due to
accidents of when your monitoring t
Ian O'Shaughnessy added the comment:
For a long running process (greatly exceeding a million iterations) the
uncollected garbage will become too large for the system (many gigabytes). A
manual execution of the gc would be required.
That seems flawed given that Python is a garbage collected l
Tim Peters added the comment:
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 woul
New submission from Ian O'Shaughnessy :
Using a script that has two classes A and B which contain a circular reference
variable, it is possible to cause a memory leak that is not captured by default
gc collection. Only by running gc.collect() manually do the circular references
get collected.
