[Python-Dev] Problems with the Python Memory Manager

[Travis E. Oliphant]

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 ....


-Travis