[ python-Bugs-858016 ] Pathological case segmentation fault in
issubclass
SourceForge.net
noreply at sourceforge.net
Sat Mar 20 18:02:46 EST 2004
Bugs item #858016, was opened at 2003-12-10 19:13
Message generated for change (Comment added) made by bcannon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858016&group_id=5470
Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Eric M. Hopper (omnifarious)
Assigned to: Brett Cannon (bcannon)
Summary: Pathological case segmentation fault in issubclass
Initial Comment:
This works for the PowerPC Python compiled with gcc 3.3
on OS X using fink. I suspect it's broader based than
that, but I don't have the ability to check properly.
Here's how to make it segment fault:
x = (basestring,)
for i in xrange(0, 1000000):
x = (x,)
issubclass(str, x)
At least, it segment faults at the interactive prompt
this way. I don't know if it does when it's executed
from a file.
----------------------------------------------------------------------
>Comment By: Brett Cannon (bcannon)
Date: 2004-03-20 15:02
Message:
Logged In: YES
user_id=357491
Fixed in both Python 2.3 and 2.4 so that the depth of the tuple cannot
exceed the the recursion limit of the interpreter.
----------------------------------------------------------------------
Comment By: Brett Cannon (bcannon)
Date: 2004-03-20 08:14
Message:
Logged In: YES
user_id=357491
Have a patch for Python 2.3 that limits the depth of the tuples to the
recursion limit of the interpreter. That will definitely be used for 2.3
Question is which solution to use for 2.4 .
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2004-02-16 15:44
Message:
Logged In: YES
user_id=31435
Well, that wasn't as much fun for you as I hoped -- the
report just sat there until I got a free holiday <wink>. Marked
Accepted and back to you -- looks good!
----------------------------------------------------------------------
Comment By: Brett Cannon (bcannon)
Date: 2003-12-18 21:24
Message:
Logged In: YES
user_id=357491
OK, Tim, start hopping. =)
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2003-12-18 13:48
Message:
Logged In: YES
user_id=31435
Oh, Brett, you're missing a chance for some fun here! A bug
should always be assigned to the next person who should "do
something" about it. Think of it as a hot potato. You should
assign the bug to who you *want* to review this, and then
sit back and watch the fun, as each person in turn tries to
unload the potato onto someone else. That's one way to get
a comforting illusion of activity here <wink>.
----------------------------------------------------------------------
Comment By: Brett Cannon (bcannon)
Date: 2003-12-18 13:39
Message:
Logged In: YES
user_id=357491
I have appended a file that adds a basic test to make sure that
when the items of a tuple are used to call isinstance or issubclass
that only classes or types are used; everything else raises
TypeError. Also tried to clarify the wording of the doc strings.
Changed the docs for isinstance since it allowed nested tupling
while issubclass' didn't.
Have a look and if someone will sign off on it I will apply the patch
and then start working on a 2.3 solution that doesn't break
semantics.
And I just realized I left out a Misc/NEWS in the patch; it will be
there when it gets applied.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2003-12-14 13:09
Message:
Logged In: YES
user_id=31435
I'm afraid that changing semantics needs to be run through
the python-dev wringer first -- "shouldn't break very much
code" isn't "shouldn't break any code". The *comments* in
these functions make it appear that they never intended to
support the OP's original code snippet, but the docs don't
match. This leaves the intent a mystery, so it needs to be
discussed.
----------------------------------------------------------------------
Comment By: Brett Cannon (bcannon)
Date: 2003-12-14 12:55
Message:
Logged In: YES
user_id=357491
OK, consider my worldview fixed. =)
I will add a check in the tuple unpacking 'for' loop to make sure it
is only passing issubclass classes and not more tuples. Simple
and shouldn't break very much code. Otherwise the code would
have to keep a count and extra bookkeeping and it would get
messy quickly.
And I will take a look at isinstance, although this tuple feature was
added in 2.3 for issubclass so it might not be an issue.
And I will backport it.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2003-12-13 17:08
Message:
Logged In: YES
user_id=31435
Yes, this needs to be fixed if it *can* be fixed without heroic
effort or insane slowdown. Looks like it can be.
Brett, the missing piece of your worldview <wink> here is that
anywhere Python can be tricked into segfaulting is a kind
of "security hole" -- it's not just mistakes we want to protect
programmers from, we also want to bulletproof against hostile
users, to the extent sanely possible.
BTW, if issubclass() has this insecurity, I bet isinstance()
does too (they were introduced & coded at the same time).
----------------------------------------------------------------------
Comment By: Eric M. Hopper (omnifarious)
Date: 2003-12-11 09:54
Message:
Logged In: YES
user_id=313
Well, I think any case where the system segment faults
unexpectedly is bad, regardless of how pathological it is.
Personally, I think that issubclass should either have a
recursion limit after which it throws an exception, or it
shouldn't go into sub-tuples at all.
The reason I made this test is that I read the description
of the behavior of issublcass and found it rather strange,
so I decided to push it to see how far it would go.
----------------------------------------------------------------------
Comment By: Brett Cannon (bcannon)
Date: 2003-12-10 20:28
Message:
Logged In: YES
user_id=357491
If you look at Object/abstract.c (line 2119 or so) for 2.4 CVS you
will notice that PyObject_IsSubclass goes into a 'for' loop for each
item in the tuple passed in and calls PyObject_IsSubclass .
Unfortunately it makes no check for whether the argument it is
passing is a class itself or not. This allows it to keep making calls
as long as the second argument is either a class or a tuple. This
is what is leads to the stack being blown and the subsequent
segfault.
Obvious solution is to put in a check that the argument about to be
passed is a class itself so as to not have such a deep call chain.
But since ``help(issubclass)`` actually makes the above use legit
(it says using a tuple as a second argument is equivalent as
passing each item to issubclass which is what it is doing, albeit in
a rather uncommon and pointless way), is it worth putting the
check in? Since this is such an obvious mis-use, I say no. But if
someone else on python-dev steps in and says otherwise I will
patch it.
----------------------------------------------------------------------
Comment By: Eric M. Hopper (omnifarious)
Date: 2003-12-10 19:16
Message:
Logged In: YES
user_id=313
I forgot this:
Python 2.3.2 (#1, Dec 4 2003, 09:13:58)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin
Type "help", "copyright", "credits" or "license" for more
information.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858016&group_id=5470
More information about the Python-bugs-list
mailing list