homepage

When tstate->overflowed is already set to 1 before entering PyErr_NormalizeException() to normalize an exception, the following cases may occur:
 1) Normalizing a built-in exception => instantiation ok.
 2) Normalizing a python exception that fails with a built-in exception => next recursion of PyErr_NormalizeException() ok.
 3) Normalizing a python exception that fails with a python exception that fails with a python exception and so on infinitely...
 => PyObject_Call() never returns and the interpreter aborts with a fatal error when the high warter mark is exceeded, the infinite recursion is in PyObject_Call().
 4) Normalizing a python exception defined in an extension module and the instantiation returns NULL and sets the same exception:
 a) Without any patch, we get a segfault caused by another bug in PyErr_NormalizeException() at Py_DECREF(*val), just before setting val to PyExc_RecursionErrorInst.
 This is fixed by changing Py_DECREF(*val) to Py_XDECREF(*val).
 With the above fix, we get the same abort as the one caused by runtimerror_singleton_2.py, so this is another reproducer of the current issue.
 b) The test is ok with patch warn_5.patch, and the above fix.
 c) With patch remove_singleton.patch the interpreter aborts with a fatal error when the high warter mark is exceeded, the infinite recursion is in PyErr_NormalizeException().
Cases 3) and 4) can be tested with runtimerror_singleton_3.py (install mymodule with setup.py for all three test cases in 4).
remove_singleton.patch introduces a regression in case c), but IMHO the abort in case c) is consistent with the abort in case 3), they
are both related to a more general problem involving the low/high water mark heuristic and described by Antoine in [1].
[1] http://thread.gmane.org/gmane.comp.python.devel/97016