[Python-Dev] Problems with the Python Memory Manager

Travis E. Oliphant oliphant.travis at ieee.org
Thu Nov 24 17:30:55 CET 2005

Armin Rigo wrote:
> Hi,
> Ok, here is the reason for the leak...
> There is in scipy a type called 'int32_arrtype' which inherits from both
> another scipy type called 'signedinteger_arrtype', and from 'int'.
> Obscure!  This is not 100% officially allowed: you are inheriting from
> two C types.  You're living dangerously!

This is allowed because the two types have compatible binaries (in fact 
the signed integer type is only the PyObject_HEAD)

> Now in this case it mostly works as expected, because the parent scipy
> type has no field at all, so it's mostly like inheriting from both
> 'object' and 'int' -- which is allowed, or would be if the bases were
> written in the opposite order.  But still, something confuses the
> fragile logic of typeobject.c.  (I'll leave this bit to scipy people to
> debug :-)

This is definitely possible.  I've tripped up in this logic before.   I 
was beginning to suspect that it might have something to do with what is 
going on.

> The net result is that unless you force your own tp_free as in revision
> 1490, the type 'int32_arrtype' has tp_free set to int_free(), which is
> the normal tp_free of 'int' objects.  This causes all deallocated
> int32_arrtype instances to be added to the CPython free list of integers
> instead of being freed!

I'm not sure this is true,  It sounds plausible but I will have to 
check.   Previously the tp_free should have been inherited as 
PyObject_Del for the int32_arrtype.  Unless the typeobject.c code copied 
the tp_free from the wrong base type, this shouldn't have been the case.

Thanks for the pointers.  It sounds like we're getting close.  Perhaps 
the problem is in typeobject.c ....


More information about the Python-Dev mailing list