From 32dd36bdceb32d72b5c4e19f9fab9953a7d041ef Mon Sep 17 00:00:00 2001 From: Nick Coghlan Date: Mon, 5 Nov 2012 20:40:25 +1000 Subject: The migration to importlib eliminated this crasher If anyone finds another recursive C path that bypasses the recursion limiting, they can add a new crasher example. --- Lib/test/crashers/recursion_limit_too_high.py | 16 ---------------- 1 file changed, 16 deletions(-) delete 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 deleted file mode 100644 index ec64936..0000000 --- a/Lib/test/crashers/recursion_limit_too_high.py +++ /dev/null @@ -1,16 +0,0 @@ -# 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 exercises 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