-
Notifications
You must be signed in to change notification settings - Fork 145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Debugger attempts to debug MicroPython subprocesses #781
Comments
This is really strange... which Python version are you using? That line in Also, I find it strange that your error says:
when it should actually say:
Those quotes around |
sorry that i left that out :
Python 3.9.7 (tags/v3.9.7:1016ef3, Aug 30 2021, 20:19:38) [MSC v.1929 64 bit (AMD64)] Linux: ./.venv-ub
Python 3.8.10 (default, Sep 28 2021, 16:10:42) |
also I have done no customization that I am aware of, and I run into the same sort of issues when I use codespaces rather than my own WSL2-Ubunto 20.04 . |
Actually the goal is not to debug the MicroPython code; I added some more test to the pattern :
additions:
So it appears that the MicroPython ( for linux) runtime somehow detects that the python debugger is active, when MicroPython runs the code and that this causes the issue. I did not expect that to be honest, and am not sure how to verify that theory I took a (very brief) look at debugpy, and the one thing that catches my eye is that it can be configured to ignore subprocesses How can I set this to ignore in the VSCode debug configuration ? I found : https://github.com/microsoft/debugpy/blob/main/doc/Subprocess%20debugging.md There only a few variables that MicroPython reads , documented, and I would not expect these to get set by debugpy. But if i know what to look for then I could perhaps clear these to allow me to debug subsequent steps in the test |
I don't think this is a MicroPython issue - it cannot really "detect" the debugger in the parent process. However, on the debugger side, we have code that, when subprocess debugging is enabled, tries to detect spawned subprocesses, and if they appear to be Python, edits the command line used to spawn them to inject the debugger before any user code runs. So this is most likely what's happening here with the MicroPython subprocess. The debugpy bug, then, is that MicroPython subprocesses are treated as regular Python subprocesses, even though we can't actually debug them. |
So we basically assume that it's Python if the binary name for the subprocess contains "python" (among other things): debugpy/src/debugpy/_vendored/pydevd/_pydev_bundle/pydev_monkey.py Lines 257 to 267 in f139ed7
debugpy/src/debugpy/_vendored/pydevd/_pydev_bundle/pydev_monkey.py Lines 378 to 380 in f139ed7
A whitelist isn't viable here, unfortunately, since there are so many possible variations on the Python binary name. We'll probably have to specifically exclude MicroPython, CircuitPython etc. OTOH it means that if you rename your MicroPython binary, or symlink to it, it should work. |
just to circle back : setting it would be very cool if that could debug MicroPython, but trust you when you say that this is not possible. |
It's possible in principle, since MicroPython has the requisite |
@int19h @karthiknadig do you think we should do something in this issue or is the status quo reasonable right now? |
I think we're good for now. If there are more similar issues, we might consider adding an exclusion list. |
@Josverl I did not want to set @int19h pointed at I now wrote a function to 'un monkey patch' which prevents the subprocess to be started in the debugger.: def un_monkey_patch():
"""
Prevent vstudio by debugging subprocesses.
This will be applied for ALL SUBSEQUENT subprocesses!
This is done by reverting the mocks
from https://github.com/microsoft/debugpy/blob/main/src/debugpy/_vendored/pydevd/_pydev_bundle/pydev_monkey.py.
"""
for module_name in ("os", "_posixsubprocess", "subprocess", "_subprocess"):
try:
module = __import__(module_name)
except ModuleNotFoundError:
continue
prefix_original = "original_"
for function_name_mock in module.__dict__.keys():
if not function_name_mock.startswith(prefix_original):
continue
function_name = function_name_mock[len(prefix_original) :]
setattr(module, function_name, getattr(module, function_name_mock)) This is now part of octoprobe: https://github.com/octoprobe/octoprobe/blob/main/src/octoprobe/util_vscode_un_monkey_patch.py @int19h: Pavel, could above code be added by debugpy. So I just could call it and would not have to maintain it. Another solution could be an environment variable |
Note that I'm not a debugpy maintainer anymore. That said, it does look like it could be a useful addition to debugpy API. It already has |
Issue Type: Bug
[tests/test_101.py][] just as a sanity check
[tests/test_spr.py][] using subprocess.run to run a linux process
Expected :
[ ] pytest to run both tests successfully
[ ] vscode python testing to run both tests successfully
[ ] vscode to be able to debug both tests successfully
Actual
[x] pytest to run both tests successfully
[x] vscode python testing to run both tests successfully
[x] tests/test_101.py
[x] tests/test_spr.py
[ ] vscode to be able to debug both tests successfully
[x] tests/test_101.py
[ ] tests/test_spr.py subprocess.run Fails while debugging with the below error:
Full repro in repo : https://github.com/Josverl/pytest_subprocess_run
Extension version: 2021.11.1422169775
VS Code version: Code 1.62.1 (f4af3cbf5a99787542e2a30fe1fd37cd644cc31f, 2021-11-05T10:57:55.946Z)
OS version: Windows_NT x64 10.0.22000
Restricted Mode: No
Remote OS version: Linux x64 5.10.60.1-microsoft-standard-WSL2
Remote OS version: Linux x64 5.10.60.1-microsoft-standard-WSL2
System Info
gpu_compositing: enabled
multiple_raster_threads: enabled_on
oop_rasterization: enabled
opengl: enabled_on
rasterization: enabled
skia_renderer: enabled_on
video_decode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled
A/B Experiments
The text was updated successfully, but these errors were encountered: