Set sys.setrecursionlimit to 50 or lower. Then, the second time the
recursion limit is reached, the interpreter crashes with a stack
overflow.
This happens both with released 3.0.1 and the py3k branch, on Windows.
At least on my PC, 51 appears to be the minimum acceptable value for
sys.setrecursionlimit.

Python 3.1a0 (py3k, Feb 28 2009, 04:16:04) [MSC v.1500 32 bit (Intel)] 
on win32
Type "help", "copyright", "credits" or "license" for more information.
p3> import sys
p3> sys.setrecursionlimit(20)
p3> def g(): g()
...
p3> g()
Traceback (most recent call last):
...
RuntimeError: maximum recursion depth exceeded
p3> g()
Fatal Python error: Cannot recover from stack overflow.

This application has requested the Runtime to terminate it in an
unusual way.
Please contact the application's support team for more information.

C:\APPS\python\py3k\PCbuild>

I can reproduce that (with the same limits) on Linux here.
It doesn't happen with 2.6.

(Although it is technically not a crash but a controlled abort().)

This is probably due to the recursion overflow recovery code in py3k,
which has a hard-wired constant of 50 somewhere :-)

(is setting the recursion limit so low a requirement for your
application? or were you just experimenting with it? as Georg said, it's
not a crash but a deliberate fatal error... although we can probably
change the behaviour when the recursion limit is set to 50 or lower)

It is an artificial value, I don't require a recursion
limit so low in any application. I found it when
looking into bpo-5370.
If there is a lower limit to sys.setrecursionlimit,
maybe it should be enforced. But since it fails only
the second time, it looks like a bug somewhere.

The fact it fails only the second time is by design, although I'm not
sure the design is useful, and it's probably not documented anywhere.
The error message says it : "Cannot *recover* from stack overflow",
which means there was a first stack overflow, and Python thinks it has
failed recovering from it since a second stack overflow occurred
afterwards.

We could probably make the recovery detection smarter.

Here is a patch. I've put the tests in test_sys.py, I haven't found a
better place for them.

The fact it fails only the second time is by design, although I'm not
sure the design is useful, and it's probably not documented anywhere.

It helped me debug a number of interpreter crashes in 3.0. When a stack
overflow occurred, in certain cases, the interpreter would catch the
exception, and consider it as failure in the callback it tried to invoke
(e.g. when invoking __eq__ during dictionary lookups). Rather than
letting the stack unwind, it would continue to let the stack overflow,
and eventually managed to crash the entire process. The recovery check
is there to detect that, after a stack overflow, it really unwound a
sufficient number of stack frames, rather than overflowing again and
again.

Committed in r70344.