Which Python memory‑leak patterns persist in CPython 3.12?

Reclamation of Cycles with __del__

Yes, CPython 3.12 reclaims memory for reference cycles containing objects with __del__ methods. The long-standing issue where such cycles were marked as "uncollectable" was resolved in Python 3.4 via PEP 442. The garbage collector (GC) can now safely break these cycles and call the finalizers.

Persistent Memory Leak Patterns

While the GC can break the cycle, "apparent" leaks persist in CPython 3.12 due to the following patterns:

• C-Extension Mismatches: If a reference cycle involves a C-extension object that does not correctly implement the tp_traverse and tp_clear slots, the GC cannot identify the cycle, leading to a permanent leak.
• External Resource Retention: The GC reclaims the Python object, but if __del__ is relied upon to close system handles (sockets, file descriptors), these resources remain open until the object is actually collected. Because GC collection is non-deterministic, this manifests as a resource leak.
• Global Root References: Objects in a cycle that are also referenced by a module-level global or a long-lived cache are never considered unreachable, preventing the GC from ever triggering the __del__ method.

Implementing weakref.finalize

Using weakref.finalize is the preferred alternative to __del__. It separates the cleanup logic from the object's lifecycle, ensuring that the cleanup function is called when the object is reclaimed without interfering with the GC's ability to identify the object as unreachable.

Verification Steps:

1. Detect Cycles: Use gc.set_debug(gc.DEBUG_LEAK) to identify objects that the GC cannot reclaim.
2. Inspect Heap: Use the tracemalloc module to take snapshots of memory before and after a suspected leak cycle is created.
3. Force Collection: Call gc.collect() manually to verify if memory is reclaimed immediately or if it persists.

import gc
import weakref

class Resource:
    def __init__(self):
        self.cycle = self  # Create a cycle
        self._finalizer = weakref.finalize(self, self._cleanup)

    @staticmethod
    def _cleanup():
        print("Resource cleaned up")

res = Resource()
del res
gc.collect() # Triggers the finalizer

Diagnostic Detail Required: Are the objects in your cycles implemented in pure Python, or do they involve C-extension types (e.g., NumPy arrays, database drivers)? This determines if the leak is a logic error or a C-API implementation failure.