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

[M.-A. Lemburg]

"Martin v. Loewis" wrote:
> 
> > Does anyone have suggestions for how to detect unbounded recursion
> > in the Python core on Unix platforms?
> 
> I just submitted patch 101352, at
> 
> http://sourceforge.net/patch/?func=detailpatch&patch_id=101352&group_id=5470
> 
> This patch works on the realistic assumption that reliable stack usage
> is not available through getrusage on most systems, so it uses an
> estimate instead. The upper stack boundary is determined on thread
> creation; the lower stack boundary inside the check. This must allow
> for initial stack frames (main, _entry, etc), and for pages allocated
> by on the stack by the system. At least on Linux, argv and env pages
> count towards the stack limit.
> 
> If some systems are known to return good results from getrusage, that
> should be used instead.
> 
> I have tested this patch on a Linux box to detect recursion in both
> the example of bug 112943, as well as the foo() recursion; the latter
> would crash with stock CVS python only when I reduced the stack limit
> from 8MB to 1MB.
> 
> Since the patch uses a heuristic to determine stack exhaustion, it is
> probably possible to find cases where it does not work. I.e. it might
> diagnose exhaustion, where it could run somewhat longer (rather,
> deeper), or it fails to diagnose exhaustion when it is really out of
> stack. It is also likely that there are better heuristics. Overall, I
> believe this patch is an improvement.
> 
> While this patch claims to support all of Unix, it only works where
> getrlimit(RLIMIT_STACK) works. Unix(tm) does guarantee this API; it
> should work on *BSD and many other Unices as well.
> 
> Comments?

See my comments in the patch manager... the patch looks fine
except for two things: getrlimit() should be tested for
usability in the configure script and the call frequency
of PyOS_CheckStack() should be lowered to only use it for
potentially recursive programs.

Apart from that, this looks like the best alternative so far :-)

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