[Python-bugs-list] [ python-Bugs-532646 ] Recursive class instance "error"

noreply@sourceforge.net noreply@sourceforge.net
Fri, 07 Jun 2002 15:52:55 -0700


Bugs item #532646, was opened at 2002-03-20 13:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Gregor Mirai (gregmi)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Recursive class instance "error"

Initial Comment:
If one writes the following code (tested on Python  
2.1, 2.2 on platforms MacOS X Server, MacOS X, Windows 
98, NT, 2000) one can easily produce several "errors".

MacOS X, MacOS X Server (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name,
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
Segmentation fault

Win98, NT, 2000 (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
foo
__repr__ __call__ __call__ __call__ ... ad inf



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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 18:52

Message:
Logged In: YES 
user_id=33168

The recursion fields are shared in the new patch.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 16:35

Message:
Logged In: YES 
user_id=33168

That sounds more reasonable.
I'll take a look and see if they can be integrated.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-07 16:27

Message:
Logged In: YES 
user_id=6380

Fair enough.  Ideally this should share the recursion_limit
variable from ceval.c and the recursion_depth field of the
stack frame.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 16:23

Message:
Logged In: YES 
user_id=33168

I don't know.  I tried to come up with other test cases and
failed.
Tried __str__ and __getitem__.  Also tried new-style classes.

The problem was that the code bounced back and forth
between PyObject_Call() & instance_call() (mutual recursion).


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-07 16:08

Message:
Logged In: YES 
user_id=6380

Is this fix enough?  Aren't there lots of other ways to
generate the same error?  E.g. new-style classes (where this
particular example doesn't apply, but others might).

Or is this specific to instance_call?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-07 15:21

Message:
Logged In: YES 
user_id=33168

The attached patch stops the segfault and raises an exception:
TypeError: 'A' max recursion limit (100000) exceeded

I'm not sure if this is genarally applicable, or what a
reasonable # is.
100,000 was a guess and should probably be made a #def
w/comment.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-21 04:47

Message:
Logged In: NO 

>>> a=A() 
>>> a.foo 
foo 
__repr__ __call__ __call__ __call__ ... ad inf

This is normal behavior. The code at the top is buggy. The 
correct one is:

class A:
  def __getattr__(self, name):
    if name == '__repr__':
      return self.__repr__()
    print name
    return A()

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-20 17:10

Message:
Logged In: YES 
user_id=6380

This is buggy user code.

But the segfault should be fixed if possible.

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

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