[Python-Dev] stack check on Unix: any suggestions?

M.-A. Lemburg mal@lemburg.com
Tue, 29 Aug 2000 21:26:52 +0200


Jeremy Hylton wrote:
> 
> Does anyone have suggestions for how to detect unbounded recursion in
> the Python core on Unix platforms?
> 
> Guido assigned me bug 112943 yesterday and gave it priority 9.
> http://sourceforge.net/bugs/?func=detailbug&bug_id=112943&group_id=5470
> 
> The bug in question causes a core dump on Unix because of a broken
> __radd__.  There's another bug (110615) that does that same thing with
> recursive invocations of __repr__.
> 
> And, of course, there's:
> def foo(x):
>     return foo(x)
> foo(None)
> 
> I believe that these bugs have been fixed on Windows.  Fredrik
> confirmed this for one of them, but I don't remember which one.  Would
> someone mind confirming and updating the records in the bug tracker?
> 
> I don't see an obvious solution.  Is there any way to implement
> PyOS_CheckStack on Unix?  I imagine that each platform would have its
> own variant and that there is no hope of getting them debugged before
> 2.0b1.

I've looked around in the include files for Linux but haven't
found any APIs which could be used to check the stack size.
Not even getrusage() returns anything useful for the current
stack size.

For the foo() example I found that on my machine the core dump
happens at depth 9821 (counted from 0), so setting the recursion
limit to something around 9000 should fix it at least for
Linux2.

> We could add some counters in eval_code2 and raise an exception after
> some arbitrary limit is reached.  Arbitrary limits seem bad -- and any
> limit would have to be fairly restrictive because each variation on
> the bug involves a different number of C function calls between
> eval_code2 invocations.
> 
> We could special case each of the __special__ methods in C to raise an
> exception upon recursive calls with the same arguments, but this is
> complicated and expensive.  It does not catch the simplest version,
> the foo function above.
> 
> Does stackless raise exceptions cleanly on each of these bugs?  That
> would be an argument worth mentioning in the PEP, eh?
> 
> Any other suggestions are welcome.
> 
> Jeremy
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://www.python.org/mailman/listinfo/python-dev

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/