Why does keeping caught exceptions in a list hold whole call frames alive, and what do you store instead?

### The chain that keeps memory alive An exception instance looks small — a type and a message. It is not. Its `__traceback__` links one node per frame it propagated through, each node holds `tb_frame`, and a frame object owns its local variables. So retaining one exception retains, transitively, every local of every frame between the `try` and the `raise`: the request payload it was parsing, the batch it was halfway through, the file buffer it had read. This is ordinary reachability, not a cycle. The cycle collector is irrelevant, and `gc.collect()` will not shrink the process. As long as your list holds the exception, everything behind it is live by definition. ### Where it bites The pattern that produces it is a good one otherwise: a long-running batch worker that keeps going after a failure and reports at the end. Say a nightly route-optimisation job processes tens of thousands of jobs and appends each failure to a list so the 11-person team gets one digest instead of a flood of alerts. Each retained exception pins the frame that was building a route, including the partially built result. A run with a few thousand failures grows steadily and can end in an out-of-memory kill *after* the useful work is done — and, because it dies at report time, the digest is never written either. A second, quieter case is any object that stores an exception for later inspection: a result wrapper, a retry record, a future's captured error, a cache of "last failure per key". If it outlives the handler, it carries frames. ### What to store instead **`traceback.TracebackException.from_exception(exc)`** is the purpose-built answer. It walks the traceback once, resolves each node into a summary with filename, line number, function name and source line, keeps the exception's type name and message, and holds **no** frame references. Its `format()` method yields the same lines the interpreter would print, so you can render the digest at the end without keeping anything live. Pass `capture_locals=True` if you deliberately want the locals — note that it stores their `repr()` strings, so the objects still are not retained, but anything sensitive in them is now in your report. **Rendered text.** `"".join(traceback.format_exception(exc))` is the crudest and often the right answer: a string is inert, bounded and trivially loggable. You lose the ability to re-render differently later, which usually does not matter. **`traceback.clear_frames(tb)`** clears the local variables of each frame in a traceback in place. Use it when something outside your control insists on keeping the exception object; the frames remain but their contents are dropped, so the rendered stack still works while the payloads are released. ### A related subtlety The language already protects the common case: the name bound by `except ... as exc:` is deleted when the block ends, precisely because the handler's own frame would otherwise reference the exception whose traceback references that frame. That protection is why casual handling does not leak — and why the leak reappears the moment you deliberately store the exception somewhere longer-lived. If you need it after the block, bind it to another name knowingly, and prefer storing a captured view rather than the object. ### How you would find it RSS that climbs with the *failure count* rather than the workload is the tell. Confirm it with allocation snapshots taken before and after a batch and diffed, and look for frame or traceback objects among the survivors; an object-graph walk from your accumulator list will show the traceback chain hanging off each stored exception. The fix is a two-line change at the append site, which is why this is worth recognising by shape rather than rediscovering by profiler each time.