[Python-bugs-list] [ python-Bugs-575229 ] multiple inheritance w/ slots dumps core

noreply@sourceforge.net noreply@sourceforge.net
Sun, 07 Jul 2002 10:25:42 -0700


Bugs item #575229, was opened at 2002-06-28 15:33
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=575229&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Cesar Douady (douady)
Assigned to: Nobody/Anonymous (nobody)
Summary: multiple inheritance w/ slots dumps core

Initial Comment:
The following script dumps a core (revision 2.2.1) :

class A(object): __slots__=()
class B(object): pass
class C(A,B) : __slots__=()
C().x=2

basic sizes for those classes are:
A => 8 (correct : no dict, no weakref)
B => 16 (correct : dict and weakref slots added)
C => 8 (incorrect : dict and weakref not inherited from
B)

in the last lines of type_new, variables add_dict and
add_weak
are exploited to add those slots, but only when
slots==NULL.
The best base selected for C is A, which is correct in
my opinion
since slots come from it, but dict and weak refs must
be treated
specially and can come from another base.

I have seen nothing in the cvs repository which may fix
this bug.

I did not submit a patch since this is a touchy part of
the interpreter,
but I may do it upon request.

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

Comment By: Greg Chapman (glchapman)
Date: 2002-07-07 09:25

Message:
Logged In: YES 
user_id=86307

FWIW, using the 2.2.1 windows binary release, I don't get an 
access violation.  However, under a debug build of 2.2.1, I do 
get an access violation.  Under the debug build (and using the 
original example), C's tp_dictoffset == tp_basicsize == 16 (all 
Python objects in a debug build have two extra pointers).  
Thus _PyObject_GetDictPtr (called when setting the 'x' 
attribute) returns a pointer which points beyond the allocated 
memory, and the access violation is generated (because 
MSVC fills the area after the allocated area with a garbage 
value).  This almost certainly means the regular build is also 
accessing memory beyond what it allocates, but it just 
happens to work in this case.  At any rate, there definitely 
appears to be a bug here.

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

Comment By: Cesar Douady (douady)
Date: 2002-07-03 08:51

Message:
Logged In: YES 
user_id=428521

oops!
I meant C.__basicsize__ is now 12 (it has slot 'a'), but
this is still less than 16.

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

Comment By: Cesar Douady (douady)
Date: 2002-07-03 08:47

Message:
Logged In: YES 
user_id=428521

I could not replicate the core dump with the latest 2.2 from
CVS,  but the problem still exist : C.__basicsize__ still is
8, which should not possible when
deriving from a class whose basic size is 16.
The following script show an abnormal behavior (actually the
one I had initially in my application):

class A(object): __slots__=('a')
class B(object): pass
class C(A,B) : __slots__=()
c=C()
c.x=2
c.a  ==> {'x':2}

In the original example, the B.__dictoffset__ would point
out of C objects, which may or may not create a core dump,
depending on a lot of factors.
In this script, B.__dictoffset__ points to slot 'a' of C,
hence 'c.x=2' creates the dictionary which is then seen as
the 'a' slot of c.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-07-02 11:13

Message:
Logged In: YES 
user_id=33168

I could not replicate this problem from current CVS
nor from 2.2.1+ (cvs).  Can you test with the CVS
versions to see if you still have a problem?

for 2.2.1+ the tag is release22-maint

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

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