From 5a9a2a3fe133000a72f69b367e552ad6180f5478 Mon Sep 17 00:00:00 2001 From: Armin Rigo Date: Tue, 25 Jul 2006 18:11:07 +0000 Subject: Added another crasher, which hit me today (I was not intentionally writing such code, of course, but it took some gdb time to figure out what my bug was). --- Lib/test/crashers/recursion_limit_too_high.py | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 Lib/test/crashers/recursion_limit_too_high.py diff --git a/Lib/test/crashers/recursion_limit_too_high.py b/Lib/test/crashers/recursion_limit_too_high.py new file mode 100644 index 0000000..1fa4d32 --- /dev/null +++ b/Lib/test/crashers/recursion_limit_too_high.py @@ -0,0 +1,16 @@ +# The following example may crash or not depending on the platform. +# E.g. on 32-bit Intel Linux in a "standard" configuration it seems to +# crash on Python 2.5 (but not 2.4 nor 2.3). On Windows the import +# eventually fails to find the module, possibly because we run out of +# file handles. + +# The point of this example is to show that sys.setrecursionlimit() is a +# hack, and not a robust solution. This example simply exercices a path +# where it takes many C-level recursions, consuming a lot of stack +# space, for each Python-level recursion. So 1000 times this amount of +# stack space may be too much for standard platforms already. + +import sys +if 'recursion_limit_too_high' in sys.modules: + del sys.modules['recursion_limit_too_high'] +import recursion_limit_too_high -- cgit v0.12