Memory leaks in Python are often straightforward to diagnose. Just look at RSS, track Python object counts, follow reference graphs. But leaks inside C extension modules are another story. Traditional memory metrics such as RSS and VMS frequently fail to reveal them because Python's memory allocator sits above the platform's native heap (see pymalloc). If something in an extension calls malloc() without a corresponding free() , that memory often won't show up where you expect it. You have a leak, and you don't know.
psutil 7.2.0 introduces two new APIs for C heap introspection, designed specifically to catch these kinds of native leaks. They give you a window directly into the underlying platform allocator (e.g. glibc's malloc), letting you track how much memory the C layer is actually consuming.
These C functions bypass Python entirely. They don't reflect Python object memory, arenas, pools, or anything managed by pymalloc. Instead, they examine the allocator that C extensions actually use. If your RSS is flat but your C heap usage climbs, you now have a way to see it.
Why native heap introspection matters
Many Python projects rely on C extensions: psutil, NumPy, pandas, PIL, lxml, psycopg, PyTorch, custom in-house modules, etc. And even cPython itself, which implements many of its standard library modules in C. If any of these components mishandle memory at the C level, you get a leak that:
Doesn't show up in Python reference counts (sys.getrefcount).
Doesn't show up in tracemalloc module.
Doesn't show up in Python's gc stats.
Often don't show up in RSS, VMS or USS due to allocator caching, especially for small objects. This can happen, for example, when you forget to Py_DECREF a Python object.
psutil's new functions solve this by inspecting platform-native allocator state, in a manner similar to Valgrind.
... continue reading