RetroSearch Browse

Sat Apr 15 16:42:45 CEST 2006 · https://mail.python.org/pipermail/python-dev/2006-April/063767.html

Martin v. Löwis wrote:
> Tim Peters wrote:
>> Well, there may well be a bug (or multiple bugs) underlying that one
>> too.  It's one thing for Py_Finalize() not to release all memory (it
>> doesn't and probably never will), but it's not necessarily the same
>> thing if running Py_Initialize() ... Py_Finalize() repeatedly keeps
>> leaking more and more memory.
> 
> Running Py_Initialize/Py_Finalize once leaves 2150 objects behind (on
> Linux). The second run adds 180 additional objects; each subsequent
> run appears to add 156 more.

With COUNT_ALLOCS, I get the following results: Ignoring the two initial
rounds of init/fini, each subsequent init/fini pair puts this number
of objects into garbage:

builtin_function_or_method 9
cell 1
code 12
dict 23
function 12
getset_descriptor 9
instancemethod 7
int 9
list 6
member_descriptor 23
method_descriptor 2
staticmethod 1
str 86
tuple 78
type 14
weakref 38
wrapper_descriptor 30

This totals to 360, which is for some reason higher than the numbers
I get when counting the objects on the global list of objects.
Is it not right to obtain the number of live object by computing
tp->tp_allocs-tp->tp_frees?

Regards,
Martin

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2006-April/063767.html below:

[Python-Dev] Py_Finalize does not release all memory, not even closely