Add python 3.15 to tests - #2069
Conversation
Verify that an exception already reported as unhandled remains recognized after a nested exception replaces the transient exception state. This prevents the original exception from being reported twice.
Track the identity of an exception once it has been reported as unhandled so that nested exceptions cannot cause it to be reported again. Clear the transient exception state before stopping while retaining the reported exception tag for the remainder of its unwind. This fixes duplicate SystemExit stops exposed by Python 3.15, where traceback formatting can trigger a nested monitored exception while resolving its lazy _colorize import.
Regenerate the .pyx and .c files from the modified _pydevd_sys_monitoring.py implementation.
Python 3.15 propagates the multithreaded os.fork() DeprecationWarning as an exception when warnings are configured as errors. Debuggee test sessions set PYTHONWARNINGS=error, and debugpy's worker threads cause CPython to emit this warning during the multiprocessing fork tests. The child process has already been created when the warning is raised in the parent. This terminates the parent while the child is attaching, resulting in premature terminated events or test timeouts. Ignore only this specific warning when the test intentionally uses the fork start method. Other warnings remain errors, and spawn-based tests are unaffected.
|
The tests are all passing now. There were 2 issues uncovered by updating to 3.15. The smaller issue was that there was a deprecation warning for calling This was fixed by adding a step in those tests to ignore that specific deprecation warning since those tests were specifically testing The larger issue involved duplicate exception stops when using the While pydevd was processing the first unhandled When execution continued, the original This second issue was fixed by tracking an already-reported exception separately from the temporary state used to find its unhandled boundary. Nested exceptions then can replace the temporary state, but won't erase the record that the original exception has already caused a debugger stop. Also, a test was added to check this specific bug instead of relying on it incidentally getting triggered by an unrelated change in the timing of when a module gets imported. |
2 participants
No description provided.