This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients ajaksu2, gvanrossum, pitrou
Date 2008-08-14.20:07:10
SpamBayes Score 5.720276e-07
Marked as misclassified No
Message-id <1218744433.5.0.965522746317.issue3555@psf.upfronthosting.co.za>
In-reply-to
Content
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?
History
Date User Action Args
2008-08-14 20:07:13pitrousetrecipients: + pitrou, gvanrossum, ajaksu2
2008-08-14 20:07:13pitrousetmessageid: <1218744433.5.0.965522746317.issue3555@psf.upfronthosting.co.za>
2008-08-14 20:07:12pitroulinkissue3555 messages
2008-08-14 20:07:10pitroucreate