[ python-Bugs-839548 ] Bug in type's GC handling causes segfaults

[SourceForge.net]

Bugs item #839548, was opened at 2003-11-10 16:32
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839548&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
>Priority: 8
Submitted By: Jim Fulton (dcjim)
Assigned to: Tim Peters (tim_one)
Summary: Bug in type's GC handling causes segfaults

Initial Comment:
type has a bug in it's GC "clear" function, type_clear.

It sets tp->mro to NULL, but other code (especially
PyObject_GenericGetAttr) assumes that tp_mro cannot be
null.

A class participating in a cycle may have clear called
while there are still instances around.  If someone
tries to do a getattr on such an instance, python will
crach with a segfault or with an assertion error.

A simple fix is for clear to set tp_mro to an empty tuple, 
which breaks the cycle without breaking the invariant.  
A patch is attached.

I encountered this in Zope 3 after adding a new
interface implementation that made heavy use of
weakrefs. Often Zope 3 would segfault when exiting. 
The patch fixes this.

Unfortunately, I was not able, in the time available,
to come up with a simpler test case. :)



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

>Comment By: Tim Peters (tim_one)
Date: 2003-11-20 16:20

Message:
Logged In: YES 
user_id=31435

Boosted priority.

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

Comment By: Tim Peters (tim_one)
Date: 2003-11-16 22:23

Message:
Logged In: YES 
user_id=31435

Assigned to me.  Please see patch 843455, which should 
repair the problem, but via a different route:  the underlying 
problem is that gc never expected that arbitrary Python code 
could run while gc is running.  A lot of bad things can go 
wrong.  But weakref callbacks have enough nice exploitable 
properties that I think it's possible for gc to run them if it's 
made acutely aware of them, and the patch does that, 
ensuring that a callback (or even later Python code, if a 
callback resurrects dead objects in cycles) never sees an 
object on which tp_clear() has been run.  In particular, then, 
in your callback the __mro__ won't be NULL -- or anything 
else surprising (it will be what you expect the class's __mro__ 
to be).

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

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