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.
diff --git a/Objects/typeobject.c b/Objects/typeobject.c
index 439676f..760ef95 100644
--- a/Objects/typeobject.c
+++ b/Objects/typeobject.c
@@ -4590,7 +4590,16 @@
if (meth == NULL)
return NULL;
+
+ /* PyObject_Call() will end up calling slot_tp_call() again 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;
res = PyObject_Call(meth, args, kwds);
+ Py_LeaveRecursiveCall();
+
Py_DECREF(meth);
return res;
}