Easy Post Mortem Function

[Sharpz7]

Hey Folks, feel free to close if this is not appropriate.

I am aware this has been brought up in different forms (https://github.com/microsoft/debugpy/issues?q=is%3Aissue+post+mortem+is%3Aclosed), but looking through the solutions, I never saw anything as simple as https://docs.python.org/3/library/pdb.html#pdb.post_mortem

So I created https://github.com/SharpSet/afterthought, which works pretty much as a direct equivalent to pdb.post_mortem, and uses debugpy behind the scenes with less than 30 lines of boilerplate.

import afterthought


def bombs():
    a = []
    print(a[0])


if __name__ == "__main__":
    try:
        bombs()
    except Exception as e:
        afterthought.debug(e)

I think it would make sense for this to exist within debugpy directly. If this is not of interest, I still would like to keep this issue here so people can see how I handled it. To the best of my knowledge I couldn't find anything this simple.

Thanks :))

[nshepperd]

I've been using the following to trigger postmortem debugging when debugging code in the vscode debugger:

import sys
import threading


def maybe_debugpy_postmortem(excinfo):
    """Make the debugger enter and stop at a raised exception.

    excinfo: A (type(e), e, e.__traceback__) tuple. See sys.exc_info()
    """
    exc_type, exc_value, exc_tb = excinfo

    try:
        import debugpy
        import pydevd  # type: ignore
    except ImportError:
        # If pydevd isn't available, no debugger attached; do nothing.
        return

    if not debugpy.is_client_connected():
        return

    py_db = pydevd.get_global_debugger()
    thread = threading.current_thread()
    additional_info = py_db.set_additional_thread_info(thread)
    additional_info.is_tracing += 1
    try:
        py_db.stop_on_unhandled_exception(py_db, thread, additional_info, excinfo)
    finally:
        additional_info.is_tracing -= 1


def debugpy_pm_tb():
    maybe_debugpy_postmortem(sys.exc_info())

This no longer works since python 3.12, with the new sys.monitoring system. Because the embedded pydevd does not use is_tracing as a reentrancy guard any more with sys.monitoring, this results in the pydevd triggering a LINE event (from certain modules that aren't in the pydevd_dont_trace_files.py: json.init, json.encoder, contextlib, tokenize) in the middle of the process of suspending, which tries to call do_wait_suspend inside itself and breaks everything. I've been unable to decipher how exactly it prevents this from happening when postmortem debugging is triggered normally, from an unhandled exception escaping the program.

A simple postmortem debugging function that just works would be really nice...

[nshepperd]

the following nonsense works, but only if env variable PYDEVD_USE_CYTHON=NO is set before loading:

    additional_info = py_db.set_additional_thread_info(thread)
    additional_info.is_tracing += 1
    thread_info = None
    saved_trace = False
    if hasattr(sys, 'monitoring'):
        from _pydevd_sys_monitoring._pydevd_sys_monitoring import _get_thread_info
        thread_info = _get_thread_info(True, 1)
        saved_trace = thread_info.trace
        thread_info.trace = False

    try:
        py_db.stop_on_unhandled_exception(py_db, thread, additional_info, excinfo)
    finally:
        additional_info.is_tracing -= 1
        if thread_info is not None:
            thread_info.trace = saved_trace         

it's not great