mirror of
https://github.com/python/cpython.git
synced 2025-11-01 18:51:43 +00:00
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).
This commit is contained in:
parent
4df7c0a55b
commit
5a9a2a3fe1
1 changed files with 16 additions and 0 deletions
16
Lib/test/crashers/recursion_limit_too_high.py
Normal file
16
Lib/test/crashers/recursion_limit_too_high.py
Normal file
|
|
@ -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
|
||||
Loading…
Add table
Add a link
Reference in a new issue