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.

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

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.

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.

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.

Logged In: YES 
user_id=6380

Thanks! Definitely a bug, and your analysis hits the nail
right on the head. I'll come up with a fix shortly. I can
still reproduce this in a debug build of 2.3 (i.e. current CVS).

Logged In: YES 
user_id=6380

I've checked in a fix for 2.3 into current CVS.

I think I'll leave this broken for 2.2; the fix was *really*
hairy.