> Assertion failed: !PyErr_Occurred(), file Objects/abstract.c, line 2158

Quick reminder: it's not a major bug if PyObject_Call() is called with an exception set. The exception will be kept in some cases. But I added the assertion because the exception is lost in some other cases. Example: calling hasattr(obj, name) replaces the current exception with an AttributeError and then clears the AttributeError exception if the object doesn't have the attribute.

> My guess is that fork() has failed,

Oh good job, it's exactly that: I'm able to reproduce the bug with your unit test (from your attached patch).

If I recall correctly, there is no overallocation on Solaris (OpenIndiana), and this buildbot is running low memory (MemoryError is very common). fork() can likely fail under low memory.

> and because preexec_fn is in use, the code tries to call gc.enable() with the fork() exception already set. My patch adds a test and fixes that.

Hum, I think that your patch can be simplified. Replace:

    if (pid == -1) {
        PyErr_SetFromErrno(PyExc_OSError);
    ...
    if (need_to_reenable_gc && _enable_gc(gc_module)) ...

with:

    if (need_to_reenable_gc && _enable_gc(gc_module)) ...
    ...
    if (pid == -1) {
        PyErr_SetFromErrno(PyExc_OSError);

What do you think?

> Victor already fixed a similar error for the cleanup branch of subprocess_fork_exec() in Issue 22290.

I reproduced the issue on Linux with pyfailmalloc.

You can play with pyfailmalloc to try to find similar bugs. The Bitbucket repository contains the latest debug_cpython.patch which adds some more checks to make the analysis faster and more effective, and debug_cpython.gdb contains commands to run it.

https://bitbucket.org/haypo/pyfailmalloc