Why can a stack dumper built on sys._current_frames() miss the very hang it was written to diagnose?

## What the call gives you `sys._current_frames()` returns a `dict` mapping the `ident` of each thread in the current interpreter to the frame object that thread is executing right now — the innermost frame, from which you can walk outwards. Combined with `threading.enumerate()` for names and `traceback` for formatting, twelve lines of Python give you a labelled dump of every thread: ```python names = {t.ident: t.name for t in threading.enumerate()} for ident, frame in sys._current_frames().items(): print(f"--- {names.get(ident, ident)} ---") traceback.print_stack(frame) ``` The leading underscore is honest signposting: this is a CPython implementation detail. It is documented, it has been there for many releases, and plenty of production code uses it — but it carries no cross-implementation guarantee, and you should treat it as a diagnostic rather than as something a feature depends on. ## Why it is genuinely attractive Against a signal-based dump, this approach wins on several axes at once. It works on Windows, where signal registration is unavailable. Output goes wherever your logging goes — as structured records, one event per thread, with your request ids attached — instead of raw text on a file descriptor captured at startup. You can filter: dump only the worker pool, only threads whose innermost frame is in your own package, only when a queue has been non-empty for a minute. And you can trigger it from inside the process, on a condition the process itself notices, rather than needing a human with a shell. ## Why it can be blind exactly when you need it All of that depends on your dumper being **able to run Python**, and that is the assumption a hang breaks. CPython executes bytecode under a global interpreter lock. A thread holds it while running Python and releases it at intervals and around most blocking calls. But a thread that enters a long-running function in a compiled extension which does *not* release the lock holds it for the entire duration. During that window no other thread executes a single bytecode. Your dumper thread is not blocked on anything of yours; it is simply never scheduled to run Python. If you exposed the dump through an administrative endpoint, that endpoint stops responding too — and the person debugging concludes the process is completely dead, when in fact one thread is very much alive and holding everything else hostage. The same reasoning covers a wedged main thread in a single-threaded program: there is nobody left to call the function. A signal-armed `faulthandler` dump does not have this problem, because its handler is C code that runs in the signal handler and walks thread state directly without needing the interpreter lock or the eval loop. The honest summary is: build the Python-level dumper for its ergonomics, and arm the signal-level one for the case where the Python-level one cannot run. ## The frame-lifetime trap The values in the returned dict are **live frame objects**, and a frame references its locals. If you stash frames in a module-level variable to look at later, you pin every local variable of every thread — including, in a renderer, a page buffer that accounts for most of a 2.4 GB working set. Frames also participate readily in reference cycles, so the memory is not necessarily reclaimed the moment you think it is. The discipline is to format immediately into strings and drop the references: ```python frames = sys._current_frames() text = {i: "".join(traceback.format_stack(f)) for i, f in frames.items()} del frames ``` Holding a frame is also a correctness hazard in a sampling loop: repeated samples that each retain frames turn a diagnostic into a leak. ## Scope The dict covers threads of the **current interpreter** only. It is not a window into another process, and a sub-interpreter's threads are not yours to see. And like any Python-level snapshot it is racy: threads move on between the call returning and your formatting the frames, which is fine for diagnosis and wrong for anything that needs a consistent picture. A related call, `sys._current_exceptions()`, gives the exception each thread is currently handling — since Python 3.12 it returns exception instances rather than the older three-tuples. It answers a different question, but it is the natural companion when you are dumping a pool that seems to be stuck inside error handling.