Why does storing a caught exception keep its traceback frames and their locals alive?

### The chain, link by link When an exception propagates, the interpreter builds a traceback: a linked list with one entry per stack frame between the `raise` and the handler that caught it. That list is attached to the exception instance as `__traceback__`, which is what makes a printed traceback possible at the point of handling rather than at the point of failure. Each traceback entry keeps a reference to its frame object. Each frame object keeps the local variables that were live in it. So the full retention chain from a single caught exception is: ``` exception -> __traceback__ -> traceback entry -> frame -> every local in that frame -> next traceback entry -> frame -> every local in that frame -> ... ``` An exception is not a small object. It is a handle on an entire slice of the call stack as it stood at the moment of failure. ### Why this becomes a leak The pattern that produces it is deliberate and looks harmless. A batch loader collects failures so it can report them at the end: ```python errors = [] for sample_id in batch: try: load(sample_id) except LoadError as exc: errors.append(exc) ``` Every appended exception pins the locals of `load` and everything `load` called. If `load` had read a multi-megabyte record into a local, that record is retained. If `load` had opened a file or a socket and failed before closing it, that resource is retained too -- and because the object is still referenced it is never finalized, so the descriptor stays open. In a long-lived clinical-lab result loader this shows as two curves rising together: RSS, and open file descriptors, the second usually tripping a limit first and giving you a much cheaper alarm than the memory graph. The same shape appears wherever an exception outlives its handler: `self.last_error = exc` on a long-lived service object, a retry queue of failed work items carrying their exceptions, a cache of failures keyed by input, a logging call that stores the exception object instead of rendering it. ### The implicit del you did not write Python 3 makes the handler name disappear at the end of the block. This code raises `NameError` on the last line: ```python try: load(sample_id) except LoadError as exc: handle(exc) print(exc) # NameError: exc is not defined ``` The compiler wraps the handler body so that the name is deleted when the block exits. That is not tidiness for its own sake: the handler's own frame is part of the chain the exception's traceback references, so a surviving `exc` local would create a reference cycle -- frame refers to exception, exception refers to traceback, traceback refers to frame -- keeping the entire raise path alive until the cyclic collector happened to notice. Deleting the name breaks the cycle at the end of the block, immediately and deterministically. Knowing *why* that name is unbound is the part of this question interviewers actually look for. Such cycles are collectable, so this is not an unfixable leak; it is a retention with an unpredictable and possibly long delay, which in a service handling many failures is indistinguishable from a leak on any dashboard. ### Keeping the failure without keeping the stack There are three good options, in rough order of preference: 1. **Keep text, not objects.** `traceback.format_exception(exc)` renders the whole chain -- type, message, frames, source lines -- to a list of strings. Strings retain nothing. This is what almost every reporting path really wants. 2. **Drop the frames, keep the exception.** `traceback.clear_frames(exc.__traceback__)` clears the local variables out of every frame in the traceback while leaving the shape of the traceback intact, so you can still print file names and line numbers. 3. **Drop the traceback entirely.** `exc.with_traceback(None)` returns the exception with no traceback attached, which is the smallest thing that is still an exception object you can re-raise or inspect by type. Also worth naming: a `__cause__` or `__context__` chain means one stored exception can pin *several* stacks, since each chained exception carries its own traceback; and an `ExceptionGroup` holds every exception it groups, multiplying the effect. When you find frames holding memory in a leak hunt -- a walk back from a leaking object that terminates at a `frame` or a `traceback` -- a stored exception is one of the two usual explanations, the other being a generator that was never exhausted or closed.