homepage

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

Logged In: YES 
user_id=6380
This is buggy user code.
But the segfault should be fixed if possible.

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()

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.

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?

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).

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.

Logged In: YES 
user_id=33168
That sounds more reasonable.
I'll take a look and see if they can be integrated.

Logged In: YES 
user_id=33168
The recursion fields are shared in the new patch.

Logged In: YES 
user_id=6380
Can you explain how the fix works? Why does the first
comment say
/* this shouldn't be reached, but just in case */
and why is this test necesary
if (tstate->recursion_depth < Py_GetRecursionLimit()) {
???
And who *does* report the recursion error?

Logged In: YES 
user_id=33168
The problem is that there is mutual recursion
between instance_call() and PyObject_Call().
The recursion apparently goes through the eval_frame() loop.
This patch increases the recursion depth so the mutual recursion
will eventually end (otherwise, the stack grows without bounds).
ISTM the first check SHOULD be reached, but it is not.
I don't understand why. The recursion error must be set
in eval_frame().
The first block in the patch could be just this line:
 ++tstate->recursion_depth;
I didn't do it that way, since I didn't expect returning to
eval_frame(). I'm not sure if it's guaranteed to return
to eval_frame() which is why I left the first condition
in with the comment. I suppose the comment should say
something like: /* this condition doesn't seem to be triggered,
the recursion depth limit is exceeded in eval_frame */
The test for recursion_depth is necessary to ensure
that the recursion error isn't overwritten. If this check
is removed, the follow exception is raised:
 AttributeError: A instance has no __call__ method
Hopefully this makes sense.

Logged In: YES 
user_id=6380
Hm. I'm tracing this in the debugger now, and it appears
that the problem is when trying to *print* an A instance.
The statement a.foo causes the problem simply because it
returns an A instance. (Proof: "a=A().foo; print a" fails in
the print.)
I think that instance_call may not be the real cause of the
problem...

Logged In: YES 
user_id=6380
It was very specific to __call__ after all, and I found an
example that didn't involve __getattr__. See the comments I
checked in as part of the fix in classobject.c.

Logged In: YES 
user_id=357491
This was not fixed for new-style classes and still segfaults
the interpreter at least back to 2.4.
Reopening.

Logged In: YES 
user_id=33168
Please add a test case to Lib/test/crashers.

Logged In: YES 
user_id=6380
Ironically, I just found the same (?) crash in the p3yk
branch, in test_class.py (which is now testing new-style
classes for compatibility with the behavior of classic classes).
I can't fix this myself, so assigning to Brett.

Logged In: YES 
user_id=357491
The test is already in crashers: infinite_rec_3 . And it is
the same crash as in py3k; that's how I found it.

Logged In: YES 
user_id=357491
Rev. 46806 for 2.5 and rev. 46807 for 2.4 have the fix for
new-style classes.