Attached is a new approach to doing this, based on "Out-Of-Memory Testing" within http://sqlite.org/testing.html

This reads environment variables, and injects a fault at the given value of "serialno", and (optionally) ongoing failures afterwards.

I used this to find a specific bug in Python/pythonrun.c (fix is the first hunk of the patch): if moduleName is NULL, then Py_DECREF will read through NULL.

Potentially this gives the low-level machinery to support adding SQLite's approach to be added to regrtest.  Doing so would imply running each test many tens of thousands of times, so perhaps we could run "-c pass" to establish at what serialno the interpreter has fully started up, then use that as a starting point when testing other scripts/modules.

I implemented a toy version of this as Lib/test/test_malloc_fault.py, which sits in an infinite loop injecting individual allocation failures when starting up sys.executable as a subprocess.

For low numbers, this throws up segfaults within _Py_ReadyTypes' call to PyType_Ready(&PyType_Type), where PyExc_MemoryError is set but has not yet been initialized (its ob_type is NULL):
        /* this will probably fail since there's no memory and hee,
           hee, we have to instantiate this class
        */

Running this interactively with a large value for PYTHONMALLOCINJECTFAULTSAT leads to an interesting failure mode within PyRun_InteractiveLoopFlags(): every call to PyRun_InteractiveOneFlags immediately returns (the PyUnicode_FromString("stdin") in within PySys_GetObject() fails to allocate memory); this leads to a tight loop sending the total refcount to stderr:
[52812 refs]
[52812 refs]
[52812 refs]
(etc)