[Patches] [ python-Patches-980475 ] partially initialized heap allocated type objects

[SourceForge.net]

Patches item #980475, was opened at 2004-06-26 19:47
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980475&group_id=5470

Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric Huss (ehuss)
Assigned to: Nobody/Anonymous (nobody)
Summary: partially initialized heap allocated type objects

Initial Comment:
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.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-07-05 18:26

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

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=980475&group_id=5470