There is a problem if you try to dealloc a partially initialized heap allocated type object. Because PyObject_GC_TRACK is not typically called until initialization is done, the gc_refs value is set to GC_UNTRACKED. In type_dealloc, it calls _PyObject_GC_UNTRACK which skips the check to see if it is GC_UNTRACKED. This patch fixes it so that it calls PyObject_GC_UnTrack to correctly handle this case.
Logged In: YES user_id=31435 Well, it's not intended that type_dealloc be robust against insane objects. If you leave type->tp_base (etc, etc) in an insane (or uninitialized) state, type_dealloc may blow up too, or lead to arbitrary memory corruption. Why is the gc tracking status special? One way it's special is that it's a place we *can* stick a useful assert to warn you when you're passing an insane object to type_dealloc -- explicitly initializing the gc_refs member to the untracked state is one of the few pieces of initialization done by the gc malloc functions. The patch would disable that sanity check, so is unattractive on that count.
Logged In: YES user_id=393416 To be honest, I didn't realize that _PyObject_GC_TRACK was being called in PyType_GenericAlloc in the type_new() function. It was a problem with my code trying to make type objects. Just have to remember to call gc_track early on.
