This only crashes on the release22-maint branch, and
only when coredump is true:

class UserLong(object):
    def __pow__(self, *args):
        pass

coredump = 1

if not coredump:
   int.__mro__

pow(0, UserLong(), 0)

It's the type of the first argument to pow() that's
relavent: if you change it to "pow(0L, UserLong(), 0)"
you then have to change "int.__mro__" to "long.__mro__"
to avoid the crash.

Maybe it was the "typeobject.c refactoring" patch that
accidentally fixed this on the trunk?

Logged In: YES 
user_id=6380

Hm, this is serious.

This can happen whenever a built-in type
isn't initialized by PyType_Ready() yet,
and for many that is pretty common.
(The call to int.__mro__ goes through
type_getattro which calls PyType_Ready().)

I'm not sure which refactoring patch
you are referring to, and I'm actually
not at all sure that this can't happen
in 2.3 (despite the fact that this
particular example doesn't core dump there).

I'll investigate more...

Logged In: YES 
user_id=6380

In fact, this still crashes in 2.2:
pow(0L, UserLong(), 0L)

Logged In: YES 
user_id=6380

OK, I nailed it.

The fix is to call PyType_Ready()
in _PyType_Lookup() when mro is NULL.

Fixed in both 2.3 and 2.2.
A test case added only for 2.3.

Logged In: YES 
user_id=6380

Argh, reopening.

There's one little detail left:
_PyType_Lookup() promises not
to set an exception.  If the call
to PyType_Ready() fails, this
promise is broken...

What to do?  PyErr_Clear()
and return NULL comes to mind...

Logged In: YES 
user_id=6380

OK, fixed that too in 2.2.x and in 2.3, by calling
PyErr_Clear().  Not ideal, but not bad either.

Logged In: YES 
user_id=6380

I'm reopening this (as a reminder to myself). Calling
PyType_Ready() from _PyType_Lookup() is fishy. It may be
that the real problem is in slot_nb_power(), which tries to
call self.__pow__(other, modulus) without checking that
self...nb_power is inseed slot_nb_power.

Logged In: YES 
user_id=6380

Fixed again, this time properly (I hope :-).