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.