Fix crash in getcurrent()/greenlet construction during early Py_FinalizeEx

[nbouvrette]

Summary

While regression-testing greenlet 3.2.5 (the backport of PR #495) against Python 3.9.7 under uWSGI, we discovered multiple independent crash paths that were not fixed by PR #495. These crashes affect Python < 3.11.

This PR fixes three root causes of SIGSEGV during Py_FinalizeEx and a latent exception-swallowing bug:

1. clear_deleteme_list() vector allocation crash: The vector copy used PythonAllocator (PyMem_Malloc), which can SIGSEGV during early Py_FinalizeEx when Python's allocator pools are partially torn down. Replaced with std::swap (zero-allocation, constant-time) and switched deleteme_t to std::allocator (system malloc).

2. ThreadState memory corruption: ThreadState objects were allocated via PyObject_Malloc, placing them in pymalloc pools that can be disrupted during finalization. Switched to std::malloc/std::free so ThreadState memory remains valid throughout Py_FinalizeEx.

3. getcurrent() crash on invalidated type objects: _Py_IsFinalizing() is only set after call_py_exitfuncs and _PyGC_CollectIfEnabled complete inside Py_FinalizeEx, so code in atexit handlers or __del__ methods could still call greenlet.getcurrent() when type objects had already been invalidated, crashing in PyType_IsSubtype. An atexit handler is now registered at module init (LIFO = runs first) that sets a shutdown flag checked by getcurrent(), PyGreenlet_GetCurrent(), and clear_deleteme_list().

4. Exception preservation: clear_deleteme_list() now preserves any pending Python exception around its cleanup loop, fixing a latent bug where an unrelated exception (e.g. one set by throw()) could be swallowed by PyErr_WriteUnraisable/PyErr_Clear.

All new code is guarded by #if !GREENLET_PY311 — zero impact on Python 3.11+.

How this was discovered

After PR #495 was merged and 3.2.5 was released, we ran our uWSGI-based crash reproducer (which simulates production worker recycling with max-requests=1) against Python 3.9.7 with greenlet 3.2.5. The segfaults persisted. Using fprintf debug tracing and objdump disassembly of crash backtraces, we narrowed the crashes to three distinct code paths, each requiring its own fix.

Root Cause Analysis

Why PR #495's guard doesn't help here

PR #495 added _Py_IsFinalizing() guards to prevent crashes during greenlet deallocation (GC-triggered, late in Py_FinalizeEx). At that point, _Py_IsFinalizing() is already true, so the guard works.

These new crashes occur earlier — during call_py_exitfuncs() (atexit handlers) and _PyGC_CollectIfEnabled(), which run before _PyRuntimeState_SetFinalizing():

Py_FinalizeEx()
├── call_py_exitfuncs()              ← crashes happen HERE
├── _PyGC_CollectIfEnabled()         ← and HERE (_Py_IsFinalizing() == false)
├── _PyRuntimeState_SetFinalizing()  ← flag set HERE (too late)
├── finalize_interp_clear()          ← PR #495's guard helps HERE

The three crash mechanisms

1. Allocator disruption: During early Py_FinalizeEx, Python's pymalloc pools can be disrupted. Any C++ object allocated via PyObject_Malloc or PyMem_Malloc (including ThreadState and its deleteme vector's internal buffer) may have its memory corrupted. Fix: use system malloc for both.

2. Type object invalidation: Python cleanup code (atexit handlers, __del__ methods) can call greenlet.getcurrent(), which returns an OwnedGreenlet smart pointer. The GreenletChecker type validator calls PyType_IsSubtype, which dereferences the greenlet's ob_type — if that type object has been freed or overwritten, SIGSEGV. Fix: an atexit handler registered at module init (last registered = first called in LIFO order) sets a flag before any other cleanup runs.

3. Exception loss: clear_deleteme_list() runs Py_DECREF + PyErr_WriteUnraisable + PyErr_Clear in a loop, which can clear a pending exception set by an earlier throw() call. Fix: save and restore the exception state around the loop using PyErrPieces.

Test plan

• Existing test_interpreter_shutdown.py passes (subprocess-based shutdown tests)
• Existing test_throw_exception_not_lost passes (exception preservation)
• Existing test_dealloc_other_thread passes (cross-thread cleanup)
• Existing test_issue251_killing_cross_thread_leaks_list passes
• Full CI on all supported Python versions (3.10–3.15)
• Manual uWSGI stress test: 0 segfaults in 200 worker recycles on Python 3.9.7 (previously 3-4 crashes in 30 recycles)

Backport note

If the maintainer plans a 3.2.x backport (for Python 3.9 support), we recommend a full sync of master into the 3.2.x branch rather than a surgical cherry-pick. All C++ changes between 3.2.4 and 3.3.x are behind #ifdef Py_GIL_DISABLED or #if GREENLET_PY312+ guards — they compile to nothing on Python 3.9, so there is zero runtime risk. Keeping the branches nearly identical (differing only in pyproject.toml and CI config) makes future maintenance significantly easier.

I can create that follow up PR once this one has been reviewed.