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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com