[Python-Dev] A "new" kind of leak

Tim Peters tim.one@comcast.net
Mon, 15 Apr 2002 00:07:33 -0400


>> An effective solution would be to bound the size of the frameobject
>> free list:

[Greg Ewing]
> I don't think that's the right solution. Won't the same problem
> occur with all the other kinds of free list as well? You'd have
> to put bounds on all of them.

tuple free lists were already bounded.  Neil found what look to be the only
other two possibilities in the core, but nobody has been able to provoke an
actual leak out of them (this has already been gone over here, and I don't
want to repeat it).

> Seems to me the correct solution is to count allocs/frees from/to
> any free list along with memory allocs/frees for the purpose of
> deciding when to do a gc.

This possibility was mentioned in the bug report, but would cost an extra
call per allocation (please don't argue about that unless you're familiar
with Python's gc code -- it's a tiny bug, and we're not going to do a
massive rework).

Since all possibilities require that vulnerable types do something they
weren't doing before, right-vs-wrong doesn't appear a sensible axis along
which to measure; bounding the free list is an easy change to a vulnerable
type's dealloc routine.