Live Process Diagnostics

Calling breakpoint() pauses the program and drops into a debugger. It dispatches through sys.breakpointhook, which by default calls pdb.set_trace. Setting PYTHONBREAKPOINT=0 makes every call a no-op; setting it to a dotted callable path routes calls there instead.

In pdb, step enters a called function, next runs the call and stays in the current frame, return finishes the current function, and until runs forward past the current line number.

Call pdb.post_mortem() with the caught exception's traceback: pdb.post_mortem(exc.__traceback__), or on 3.13+ pass the exception itself. You land in the frame that raised, with its local variables readable but not resumable.

Instead of printing a traceback and exiting, pdb catches the unhandled exception and drops you into post-mortem debugging at the frame that raised, with that frame's local variables still readable. Execution cannot be resumed from the raise point.

Because the exception references its traceback, which references the frames, which reference the exception - a cycle that would keep the whole stack alive. Python deletes the name at the end of the clause; assign the exception elsewhere first if you need it later.

Calling an async def function only builds a coroutine object; none of its body runs until something awaits it or wraps it in a task. When that unstarted object is garbage collected, CPython emits the warning.

CPython counts the Python frames stacked on the current thread and raises RecursionError once that count passes the ceiling sys.getrecursionlimit() reports, which is 1000 on a fresh interpreter. sys.setrecursionlimit() moves the ceiling; it does not enlarge the thread's real stack.

A SIGSEGV kills the process at the operating-system level before CPython can run any Python code, so there is no unwinding, no except clause and no traceback - only a shell status of 139 and possibly a core file.

Take two dumps a few seconds apart. Identical stacks at near-zero CPU means blocked; a pinned core means spinning. Then read each worker's innermost frames and find the one thread that is not waiting.

It installs handlers for fatal signals such as SIGSEGV and SIGABRT. When one fires, the interpreter writes a Python stack for each thread to stderr and then lets the process die exactly as it would have.

It retires that one code location for that event and that tool: CPython de-instruments the instruction, so the callback never fires from that spot again and later executions run at almost full speed. sys.monitoring.restart_events re-arms every retired location.

A sampling profiler interrupts the program at a fixed interval, records the current call stack, and counts how often each stack appears. A frame present in 30% of samples held the interpreter for roughly 30% of the profiled period.

The global callback set by sys.settrace fires only on 'call' events, and whatever it returns becomes that frame's local trace function, receiving the frame's 'line', 'return' and 'exception' events. Returning None means that frame is not instrumented further.

Claim a slot with sys.monitoring.use_tool_id, attach a function with sys.monitoring.register_callback, then turn the event on with sys.monitoring.set_events. Skip any one of the three and nothing is delivered; using an unclaimed tool id raises ValueError.

sys.addaudithook registers a callable that CPython invokes for every audit event, passing the event name and an argument tuple. The runtime raises events at sensitive points: compiling and executing code, importing, opening files, and starting a subprocess.

They mark the exact sub-expression that failed. Since Python 3.11 (PEP 657) every bytecode instruction carries start and end column offsets, so the traceback underlines the failing operation instead of blaming the whole line.

sys.excepthook is the callback CPython runs when an exception escapes the main thread's top level. The default prints a traceback to sys.stderr and the process exits non-zero. Replace it to log or report the crash.

traceback.format_exc() returns the full report for the exception currently being handled as one string. traceback.print_exc() renders the same text but writes it to sys.stderr and returns None. Both read the current exception, so call them inside an except block.

The suggestion is computed when the exception is displayed, not when it is raised. The message string stays "name 'x' is not defined"; the traceback machinery adds the closest matching name it can find in the failing frame.

A thread's exception never reaches the main thread's stack, so sys.excepthook is never involved. The threading bootstrap catches it and calls threading.excepthook instead, which prints 'Exception in thread ...' and lets the process carry on with an unchanged exit status.

warnings.warn() reports a problem without stopping execution: the call returns and the code keeps running. It also passes through the filter list in warnings.filters first, so the same call may print, be silenced, or be turned into a raised exception.

Python ships default entries in warnings.filters that ignore DeprecationWarning everywhere except when it is triggered from the main module. Surface them with -W default::DeprecationWarning, PYTHONWARNINGS, or a warnings.filterwarnings call.

Development mode makes a normal interpreter noisy. It adds the default warning filter so ignored categories like ResourceWarning print, installs debug hooks around memory allocations, enables faulthandler and asyncio debug mode, and sets sys.flags.dev_mode to True.

ResourceWarning is discarded by CPython's default warning filters, so nothing prints. Development mode adds the default filter, which shows it. The warning itself is emitted by the file object's finalizer when it is garbage-collected without being closed.

stacklevel picks which stack frame the warning is blamed on. The default 1 points at the warn() call itself; 2 points at that function's caller, which is what a deprecated API should report so the user sees their own line.