Open zillionare opened 2 years ago
zillionare
commented
2 years ago we have reproduced this problem, it caused by aioredis and ms-python, unitest together.
reproduce steps:
Now you'll get above exception.
If you run unittest without breakpoints, no exceptions.
Hope this helps.
zillionare
commented
2 years ago we have created a issue for tracking this: https://github.com/zillionare/omega/issues/46 the branch can reproduce this pr is: https://github.com/zillionare/omega/tree/zillionare/issue46
To reproduce:
int19h
commented
2 years ago If you set the environment variable PYDEVD_USE_FRAME_EVAL to NO, does it still repro?
zillionare
commented
2 years ago yes, it is still reproducible. If you by any chance want to reproduce this issue by yourself, make sure run several times, if it's not reproduced at the very begining.
fabioz
commented
2 years ago From the traceback it seems that there is some recursion when trying to obtain the repr or get some attribute of some object which is using the asyncio structure.
It's expected from the debugger that it asks for the string representation/gets attributes of many objects (and that objects don't stack-overflow when doing that).
The debugging probably doesn't need anything in the debugger itself... I suggest you change the repr_instance method inside of reprlib and implement some basic recursion check so that it throws an error if it it starts to recurse (say, more than 5 recursive calls) and then invoke the debugger in such a situation.
I'll leave it open for your feedback, but from the issue report (even though the debugger makes it happen), it doesn't really seem like the bug lies in the debugger, but in the code you're debugging (the whole recursion chain doesn't include anything from the debugger -- it probably works sometimes because stack-overflows don't always crash Python, only sometimes and you're seeing these times in the printed traceback, but my guess is that you're almost always getting the stack overflows and that you can discover it by doing some basic recursion check inside of repr_instance).
fabioz
commented
2 years ago I was thinking that maybe this could be turned into a feature in the debugger so that whenever a given recursion level is reached in Python the debugger could notify the user about it.
The unfortunate part is that I know of no way to just get a count for the current recursion level, so, I think the debugger would need to walk through the frame.f_back until the root is reached whenever function is entered (and that could make debugging considerably slower), but as a way to at least notify the user where this happens in cases like this it may be worth having this option even if it's slow...
Ideally we could just hook into Python to call a function when the recursion limit is reached, but I think there's no API for that.
fabioz
commented
2 years ago Mental note: we could use ctypes to get the thread state recursion_remaining to know if the recursion limit is being reached in CPython.
VS Code version
1.60.2
Extension version
python: v2021.10.1365161279
OS type
Linux
OS version
ubuntu 20.04
Python distribution
Anaconda
Python version
3.9.7 64-bit
Language server
Pylance
Expected behaviour
No exception
Actual behaviour
============================= test session starts ==============================
Steps to reproduce
Not 100% producible. Occurs more on virtual machines runs on one ESXi servers, but not always.
Logs
No response
Code of Conduct