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