[Python-Dev] Is Lib/test/crashers/recursive_call.py really a crasher? (original) (raw)

Michael Hudson mwh at python.net
Tue Jun 27 19:19:45 CEST 2006

"Brett Cannon" <brett at python.org> writes:

If you look at that crasher, you will notice that recursion depth is set to 1 << 30 before any code is run. If you remove that setting high setting and go with the default then the test doesn't crash and raises the appropriate RuntimeError.

Setting the recursion depth to such a high number will crash the interpreter even when the proper recursion checks are in place. This doesn't seem like a legit crasher to me if it requires an insane recursion depth that would crash almost any C program that had recursion in it. Anyone have any objections if I call foul on the test and remove it without any changes to Python?

Yes, it's still a way to crash Python :-) (in fact, a problem vaguely like this that made a complete test run segfault on 64-bit platforms was fixed in PyPy recently).

More seriously, the recursion limit approach is IMHO something of a hack, as the amount of bytes of C stack in between increments is rather variable (try seeing how high you have to set the recursion limit to when the recursion invovles list.sort() compared to when it doesn't). I don't have a fantastic idea for fixing this, but I quite like having some kind of reminder of it.

Cheers, mwh

-- ZAPHOD: Who are you? ROOSTA: A friend. ZAPHOD: Oh yeah? Anyone's friend in particular, or just generally well-disposed to people? -- HHGttG, Episode 7

More information about the Python-Dev mailing list