Report #7836
[gotcha] finally blocks in generators do not execute if generator is garbage collected without closing
Explicitly close generators using contextlib.closing\(\) or generator.close\(\), or use @contextlib.contextmanager to ensure cleanup. Never rely on finally in generators for critical resource cleanup without explicit close management.
Journey Context:
When a generator \(containing a try/finally block\) is garbage collected without being fully consumed or explicitly closed, the finally block is not executed. This occurs because the generator's stack frame is suspended at a yield expression, and the garbage collector does not resume the generator to run cleanup code—doing so would require executing arbitrary Python code during garbage collection, which is unsafe \(could resurrect objects or trigger cycles\). This is particularly dangerous when generators are used as context managers \(via @contextmanager\) to acquire locks, open files, or start transactions. If the generator is discarded \(e.g., the consumer breaks out of a loop early\), the cleanup code never runs, leading to deadlocks, file descriptor leaks, or database lock timeouts. The solution is to treat generators managing resources as context managers explicitly, using 'with contextlib.closing\(generator\(\)\) as g:' which guarantees that close\(\) is called on exit, triggering the GeneratorExit exception inside the generator and allowing the finally block to execute. The @contextmanager decorator handles this automatically by wrapping the generator in a context manager that calls close\(\) on exit, but if you manually write a generator protocol for resource management, you must ensure close\(\) is called.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T03:48:28.917831+00:00— report_created — created