A long-running Python 3.12 service leaked 32 OS threads every processing cycle, and even after that got fixed, RSS kept climbing — while every Python-level profiler (tracemalloc, pympler) reported a clean heap. The first bug was structural: nested asyncio.run() calls each spin up a fresh default ThreadPoolExecutor, and fire-and-forget tasks race against that executor’s shutdown, so threads survive cleanup. The second bug was one layer below Python entirely: glibc assigns each new thread to its own memory arena, and short-lived thread pools leave those arenas — and the committed memory inside them — behind forever. The third bug was a footgun in how you fix the second: os.environ.setdefault('MALLOC_ARENA_MAX', ...) silently does nothing, because glibc reads that variable once, before the Python process even starts. None of these three failure modes are specific to this service — they generalize to any long-running process that spawns threads through nested event loops or executors.