[Patches] [ python-Patches-570483 ] segfault in Objects/typeobject.c

[noreply@sourceforge.net]

Patches item #570483, was opened at 2002-06-18 13:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=570483&group_id=5470

Category: Core (C code)
Group: None
>Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Tim Northover (tnorthover)
Assigned to: Guido van Rossum (gvanrossum)
Summary: segfault in Objects/typeobject.c

Initial Comment:
The function mro_implementation segfaults when given a
type which does not have any tp_bases. Obviously this
doesn't occur usually, but since the function is
accessible from the interpreter I put a check in and
made it return a list containing only the type itself.

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

>Comment By: Tim Northover (tnorthover)
Date: 2002-06-18 16:57

Message:
Logged In: YES 
user_id=564941

There are 22 types added to builtins (in CVS). It would be
fairly easy to add these to the _Py_ReadyTypes.

If another type is obtained from an instance (a.__class__)
then the type is readied, so the only way I can think of for
any python to get hold of one is from some C code. The main
part only defines builtins really; so this leaves modules
which should obviously do their own checking.

It seems that it would catch all errors of this type if
_Py_ReadyTypes was altered. Personally I would change the
order slightly so that the base classes would get readied
first (currently the error for string could also refer to
basestring). This method seems slightly inelegant, however.
To save others the typing, here's a patch to do this in case
it is solved this way.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-18 16:52

Message:
Logged In: YES 
user_id=6380

tnorthover: thanks for the 2nd patch -- that's the proper
fix, and I've applied it now.

theller: unfortunately, there are some interdependencies
between some of the very basic types that make it really
hard to come up with a proper initialization sequence. I
tried, and failed -- PyType_Ready() ends up going into
infinite recursion.

mwh: who knows how many more like this there will be. :-(
It's hard to come up with test cases that test everything...

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

Comment By: Michael Hudson (mwh)
Date: 2002-06-18 15:17

Message:
Logged In: YES 
user_id=6656

tnorthover: no!  don't go away!

theller: maybe, but that's wasn't guido's immediate response to

[ 551412 ] possible to fail to calc mro's

and I don't understand why.

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

Comment By: Thomas Heller (theller)
Date: 2002-06-18 14:17

Message:
Logged In: YES 
user_id=11105

Wouldn't it be better to just call PyType_Ready also in the 
interpreter for all types? It seems extension writers are also 
required to do this...

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

Comment By: Tim Northover (tnorthover)
Date: 2002-06-18 14:08

Message:
Logged In: YES 
user_id=564941

Looking again at the code it seems that the problem is a
result of tuple (and possibly others) not being run through
PyType_Ready before the interpreter actually starts. The
first attempt to do anything to its attributes calls this,
so possibly a more appropriate patch would be to check if
type->tp_dict is NULL (this seems to be the standard check
for initialization) and call PyType_Ready if it isn't. 

I've implemented this and now it returns the same value as
if the type had been initialized. There is no infinite loop
on startup (which is when it would be most likely), but I
obviously don't know enough yet to make sure it is
definitely safe. (Here's another patch).

Incidentally, please tell me to go away if I'm not helping.

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

Comment By: Michael Hudson (mwh)
Date: 2002-06-18 13:35

Message:
Logged In: YES 
user_id=6656

OK, thanks.  It's similar to a bug that got fixed recently,
so I was wondering if the fix for that fixed this.  It didn't.

Your patch doesn't produce the correct behaviour, am I
right?  (admittedly, I haven't applied it).

Guido, how many more bugs like this are there going to be?

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

Comment By: Tim Northover (tnorthover)
Date: 2002-06-18 13:26

Message:
Logged In: YES 
user_id=564941

Of course, here's a transcript:
$python
Python 2.2.1 (#1, Apr 21 2002, 08:38:44)
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> type.mro(tuple)
Segmentation fault
$

Though, I've just noticed that if you explicitly access
tuple.__bases__ it gets initialized with just object and it
then works.

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

Comment By: Michael Hudson (mwh)
Date: 2002-06-18 13:12

Message:
Logged In: YES 
user_id=6656

Could you include a testcase?

Without such a hint, I'd guess Guido is the only person
capable of reviewing this...

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

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