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

[noreply@sourceforge.net]

Patches item #570483, was opened at 2002-06-18 09: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: Closed
>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: Guido van Rossum (gvanrossum)
Date: 2002-06-18 12: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 11: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 10: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 10: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 09: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 09: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 09: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