mirror of
https://github.com/python/cpython.git
synced 2025-12-15 21:44:50 +00:00
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:
parent
f92b9c21ed
commit
53c1692f6a
3 changed files with 22 additions and 11 deletions
|
|
@ -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,
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue