This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: possible to fail to calc mro's
Type: Stage:
Components: Interpreter Core Versions: Python 2.3
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: gvanrossum Nosy List: gvanrossum, mwh
Priority: normal Keywords:

Created on 2002-05-02 13:42 by mwh, last changed 2022-04-10 16:05 by admin. This issue is now closed.

Messages (8)
msg10633 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2002-05-02 13:42
This only crashes on the release22-maint branch, and
only when coredump is true:

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

coredump = 1

if not coredump:

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?
msg10634 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2002-05-24 21:10
Logged In: YES 

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...
msg10635 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2002-05-24 21:20
Logged In: YES 

In fact, this still crashes in 2.2:
pow(0L, UserLong(), 0L)
msg10636 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2002-05-24 21:42
Logged In: YES 

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.
msg10637 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2002-05-24 21:46
Logged In: YES 

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...
msg10638 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2002-06-03 19:55
Logged In: YES 

OK, fixed that too in 2.2.x and in 2.3, by calling
PyErr_Clear().  Not ideal, but not bad either.
msg10639 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2002-06-10 00:18
Logged In: YES 

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.
msg10640 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2002-06-10 14:35
Logged In: YES 

Fixed again, this time properly (I hope :-).
Date User Action Args
2022-04-10 16:05:17adminsetgithub: 36539
2002-05-02 13:42:26mwhcreate