[Python-bugs-list] [ python-Bugs-759227 ] improbable __nonzero__ crash

SourceForge.net noreply@sourceforge.net
Fri, 27 Jun 2003 10:14:26 -0700


Bugs item #759227, was opened at 2003-06-23 13:45
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=759227&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Armin Rigo (arigo)
Assigned to: Jeremy Hylton (jhylton)
Summary: improbable __nonzero__ crash

Initial Comment:
>>> class X(object):
...   def __nonzero__(self):
...     return self
... 
>>> x=X()
>>> not x
Segmentation fault

This is just a stupid artificial exploit of the fact
that PyObject_IsTrue calls the user-defined __nonzero__
and get a Python object whose truth-value itself is
determined by a call to PyObject_IsTrue.

For old-style classes we check that __nonzero__
actually returned an int. This trick was safe, but no
longer is, because it could be a subclass of int with a
custom __nonzero__ again.


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-27 17:14

Message:
Logged In: YES 
user_id=31392

I did a partial fix for this problem by restricting
__nonzero__ to return an int or a bool, as per the language
spec.  The remaining problem is for a subclass of int
returned from __nonzero__.  I think the simplest solution to
this problem is to require __nonzero__ to return exactly an
int -- PyInt_CheckExact() instead of PyInt_Check().  Does
anyone find this restriction unacceptable?


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

Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-24 20:12

Message:
Logged In: YES 
user_id=31392

I think this patch is too specialized.  It only handles the
contrived case that Armin reported.  It's possible to get
unbounded recursion in a variety of ways.  I don't see why
we should patch the code to deal with a single one.


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-24 17:49

Message:
Logged In: YES 
user_id=80475

Preventing mutually recursive calls is probably not worth it.  
Your simple patch does the trick.  Please do add a test case 
for it.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-23 17:01

Message:
Logged In: YES 
user_id=33168

Note: the patch doesn't address a case of mutual recursion
where 2 or more objects are involved.  That could be fixed
by tying the call into the recursion limit.  Not sure how
difficult that is or if it's worth it.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-06-23 16:58

Message:
Logged In: YES 
user_id=33168

This is also a 2.2.3 problem.  This seems easy enough to fix
(patch attached), but the question is what should the answer
be?  I made it return 1 (true).  Should it be an exception?

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

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