Message71148
I'm no expert in recursion checking inside the Python interpreter, but
looking at the code for _Py_CheckRecursiveCall(), I don't think it is a
bug but a feature.
Here how I understand it. When the recursion level exceeds the normal
recursion limit (let's call the latter N), a RuntimeError is raised and
the normal recursion check is temporarily disabled (by setting
tstate->overflowed) so that Python can run some recovery code (e.g. an
except statement with a function call to log the problem), and another
recursion check is put in place that is triggered at N+50. When the
latter check triggers, the interpreter prints the aforementioned
Py_FatalError and bails out.
This is actually what happens in your example: when the normal recursion
limit is hit and a RuntimeError is raised, you immediately catch the
exception and run into a second infinite loop while the normal recursion
check is temporarily disabled: the N+50 check then does its job.
Here is a simpler way to showcase this behaviour, without any nested
exceptions:
def f():
try:
return f()
except:
pass
f()
f()
Can someone else comment on this? |
|
Date |
User |
Action |
Args |
2008-08-14 20:07:13 | pitrou | set | recipients:
+ pitrou, gvanrossum, ajaksu2 |
2008-08-14 20:07:13 | pitrou | set | messageid: <1218744433.5.0.965522746317.issue3555@psf.upfronthosting.co.za> |
2008-08-14 20:07:12 | pitrou | link | issue3555 messages |
2008-08-14 20:07:10 | pitrou | create | |
|