[Python-bugs-list] [ python-Bugs-551412 ] possible to fail to calc mro's

[noreply@sourceforge.net]

Bugs item #551412, was opened at 2002-05-02 09:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=551412&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Guido van Rossum (gvanrossum)
Summary: possible to fail to calc mro's

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

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-10 10:35

Message:
Logged In: YES 
user_id=6380

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

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-09 20:18

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

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-03 15:55

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

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 17:46

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

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 17:42

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

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 17:20

Message:
Logged In: YES 
user_id=6380

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

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-05-24 17:10

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


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

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