This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Deal better with StackOverflow exception when debugging
Type: crash Stage:
Components: Interpreter Core Versions: Python 3.9, Python 3.8, Python 3.7, Python 3.6, Python 3.5
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: almenon anon
Priority: normal Keywords:

Created on 2019-09-04 00:18 by almenon anon, last changed 2022-04-11 14:59 by admin.

Messages (1)
msg351107 - (view) Author: almenon anon (almenon anon) Date: 2019-09-04 00:18
Code that runs fine in the command line can crash in the debugger

Note that because https://bugs.python.org/issue10933 is not fixed yet I'm assuming this applies to all python 3 versions but it was confirmed in python 3.6

See https://github.com/microsoft/ptvsd/issues/1379:

@fabioz says it better than I could:

> This is really a CPython bug, not ptvsd (CPython is crashing because of a stack overflow when the stack overflow is thrown inside a tracing function -- because the user code already recursed too much).

> As a note, the debugger is even disabled on the face of a stack overflow (see: https://bugs.python.org/issue10933), so, even if it didn't crash, things wouldn't work very well from that point onwards...

> Maybe we could try to detect that a stack overflow is about to happen and notify about it right before it happens in the debugger so that users could know that the debugger would stop (note that this is actually pretty hard to do from the debugger without killing performance because we don't have a stack in the debugger as we try to run with frames untraced whenever possible and I don't think there's a python API that provides the size of the stack in a fast way -- but maybe I'm wrong, I haven't investigated much).

> As a note, the ideal place for that would probably be in CPython itself (when it got to that condition it could raise the recursion limit a bit and call a handler or at least give some warning if configured to do so as it can be really puzzling to know that the tracing got disabled because of a swallowed StackOverflow).

> So, I'm going to rename this issue to Deal better with StackOverflow in CPython so that it reflects better the issue at hand, but it's not currently high-priority -- that's really a bug in CPython itself and is probably better fixed there (the workaround in user code -- in this case foxdot -- is not throwing a StackOverflow).
History
Date User Action Args
2022-04-11 14:59:19adminsetgithub: 82204
2019-09-04 00:18:43almenon anoncreate