Fix for an obscure bug introduced by revs 46806 and 46808, with a test.

The problem of checking too eagerly for recursive calls is the
following: if a RuntimeError is caused by recursion, and if code needs
to normalize it immediately (as in the 2nd test), then
PyErr_NormalizeException() needs a call to the RuntimeError class to
instantiate it, and this hits the recursion limit again...  causing
PyErr_NormalizeException() to never finish.

Moved this particular recursion check to slot_tp_call(), which is not
involved in instantiating built-in exceptions.

Backport candidate.
This commit is contained in:
Armin Rigo 2006-06-21 21:58:50 +00:00
parent f92b9c21ed
commit 53c1692f6a
3 changed files with 22 additions and 11 deletions

View file

@ -1796,17 +1796,7 @@ PyObject_Call(PyObject *func, PyObject *arg, PyObject *kw)
ternaryfunc call;
if ((call = func->ob_type->tp_call) != NULL) {
PyObject *result = NULL;
/* slot_tp_call() will be called and ends up calling
PyObject_Call() if the object returned for __call__ has
__call__ itself defined upon it. This can be an infinite
recursion if you set __call__ in a class to an instance of
it. */
if (Py_EnterRecursiveCall(" in __call__")) {
return NULL;
}
result = (*call)(func, arg, kw);
Py_LeaveRecursiveCall();
PyObject *result = (*call)(func, arg, kw);
if (result == NULL && !PyErr_Occurred())
PyErr_SetString(
PyExc_SystemError,