This bug was originally found by a colleague. Memory usage (RSS) keeps increasing even though allocated blocks stays essentially constant. Self contained reproducer below:

import gc
import sys
import os
import concurrent.futures

def get_rss_mb():
    with open("/proc/self/statm") as f:
        return int(f.read().split()[1]) * os.sysconf("SC_PAGE_SIZE") / (1024 * 1024)

def work(_):
    return [bytearray(64) for _ in range(4000)]


NUM_ITERATIONS = int(sys.argv[1]) if len(sys.argv) > 1 else 20

pool = concurrent.futures.ThreadPoolExecutor(max_workers=4)
for i in range(NUM_ITERATIONS):
    futures = [pool.submit(work, j) for j in range(100)]
    results = [f.result() for f in futures]
    del futures, results  # free worker-allocated objects on main thread
    gc.collect()
    gc.collect()
    blocks = sys.getallocatedblocks()
    print(f"iter {i:3d}: RSS={get_rss_mb():7.1f} MB {blocks=}")

pool.shutdown()
print(f"after shutdown: RSS={get_rss_mb():7.1f} MB")

The problem is that we end up having orphaned mimalloc pages in the full queue, even though those pages have available blocks or are completely empty. They're "leaked" until the thread exits.

NOTE: The bugs are limited out our mimalloc modifications. They're not in upstream mimalloc.

I think there are at least two underlying bugs here:

1. _PyMem_mi_page_maybe_free leaves empty pages in the full page queue. This bug can happen when a page goes from "full" to "all free".
2. _mi_page_free_collect calls _PyMem_mi_page_clear_qsbr if page->local_free != NULL. This can get erroneously triggered even the by traversing heaps. We only want to clear the page QSBR counter when it becomes empty again.

Additionally, _PyMem_mi_page_maybe_free can insert pages into the wrong mimalloc list. _PyMem_mi_page_maybe_free inserts the page into the current thread's list. However, during GC and other stop-the-world pauses, we may traverse the heaps of other threads. That traversal does some processing of free lists, which can end up calling _PyMem_mi_page_maybe_free. In that case, we should insert the page into the owning thread's list, not the current thread's list. Otherwise, we can end up with a data race later on.

Linked PRs

• gh-145615: Fix mimalloc page leak in the free-threaded build #145626
• [3.14] gh-145615: Fix mimalloc page leak in the free-threaded build (gh-145626) #145691