This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients brett.cannon, mark.dickinson, ncoghlan
Date 2010-05-05.22:07:37
SpamBayes Score 0.00023808746
Marked as misclassified No
Message-id <1273097260.94.0.991006635428.issue8627@psf.upfronthosting.co.za>
In-reply-to
Content
I haven't looked at this in a while, but I do remember it was hard to get working at all without a ridiculous number of false alarms - type initialisation isn't the most straightforward thing in the world.

Agreed the warning for __cmp__ should just go away - I think we nuked the actual check in 3.1 when __cmp__ was removed, but must have missed this at the time.

For the refleak, I'm wondering if you may be seeing a problem with statically allocated type objects. type_new does a DECREF on the allocated object if PyType_Ready fails, so everything should be getting cleaned up at that point, but that won't happen for a statically allocated type.

Looking at type_clear, I suggest sticking a "Py_CLEAR(type->tp_mro);" in before the goto error line and see if that eliminates the leak. If that actually works, then I'll have my doubts about the correctness of the other "goto error" lines in PyType_Ready that happen after the call to mro_internal().
History
Date User Action Args
2010-05-05 22:07:41ncoghlansetrecipients: + ncoghlan, brett.cannon, mark.dickinson
2010-05-05 22:07:40ncoghlansetmessageid: <1273097260.94.0.991006635428.issue8627@psf.upfronthosting.co.za>
2010-05-05 22:07:38ncoghlanlinkissue8627 messages
2010-05-05 22:07:38ncoghlancreate