Debugger times out when "qt":"auto" is used with ArcGIS Python #362
Assignees
Labels
bug
Something isn't working
Comments
|
What's the command line like in the terminal? If you're using |
|
cd c:\dev\NESDI && cmd /C ""C:\Program Files\ArcGIS\Pro\bin\Python\envs\dev\python.exe" c:\Users\eykampC.vscode\extensions\ms-python.python-2020.7.96456\pythonFiles\lib\python\debugpy\launcher 49258 -- c:\dev\NESDI\delme.py " |
|
Those old issues from the ptvsd repo shouldn't be relevant here. But it probably does have something to do with ArcGIS Python. We'll need the logs to figure that out, though. Can you please add this: "logToFile": trueto your debug config, and then look for |
|
I figured those old issues were, well, old, but I looked through them just to make sure. Here are the logs. debugger.log: adapter.log: launcher.log: |
|
Or, if you prefer the files themselves: debugpy.launcher-27788.log |
|
It's interesting that it didn't produce a server log. What happens if you manually run this in the terminal? |
|
Nothing! |
|
I get a very different reaction with my default version of Python... (the only thing I changed was the python command at the beginning) |
|
The latter one is the expected behavior (it can't find the IDE side, but that's okay). Does Also, judging by the path, this is actually a conda environment - these usually require activation via |
|
Yes: What's odd is that this also works from the IDE -- When debugging fails, I can still run the script normally using the green triangle button. It is a conda environment, and I've never had an issue debugging until the most recent VSCode update, and as I noted running still works. I did try activating the environment from a cmd window, then launch code from there; I experienced the same problem. |
|
Perhaps helpful... because this problem is really crippling, I've been probing around with lots of print statements trying to figure out where things diverge between the working python (generates stack trace) and non-working python (quits silently). The issue seems to be a call in api.py, line 128: Forcing qt_mode to be "none" fixes the problem, and I can use the debugger. |
|
This is very interesting, thank you! This line relates to monkey-patching Qt so that debugger can detect |
|
My lanuch.json doesn't like the "qt" param (it says "property qt is not allowed")
|
|
Looks like the extension needs to update the schema. The squiggle in the editor shouldn't prevent it from working, though. |
|
Ok, I'll give it a shot. Regardless of whether it works or not, I have a way forward. At this time, I have no need to debug qt threads, so this workaround should not impact me at all. From my perspective, the immediate case is resolved, but I'll leave it to you to leave it open or close it, depending on whether you think there is something underlying that needs fixing. I'm happy to help if I can. And, long overdue, thank you for your help. I too sometimes support random people on the internet, and I know it's often thankless work, rewarding when it helps, but quite often results in an awkward surrender that leaves no party satisfied. Again, thank you. |
|
Thank you for the kind words! I think the remaining bug here is that either |
int19h
changed the title
|
@fabioz Let's see what the root cause is first, and how expensive fixing it would be. My biggest concern here is that it's not something specific to ArcGIS, but rather merely exposed by it due to the way it configures Qt, or perhaps the version that it uses. If |
|
Just confirming that the |
|
Since it works with a previous version and not this one, this may be the same thing as: where the environment variables in the launch appear to be different from one launch to the other due to an upgrade (and when it gets to load qt the version is conflicting -- the problem is probably that qt is being loaded too soon as ArcGis probably configures things to work out if the code goes further on). |
|
@eykamp can you run the code below in the current version of the extension as well as in the previous version and let me know if there's any difference in the environment variables from one run to the other? See: #370 (comment) for how to install a previous version. |
|
I can't easily revert the extension (or the editor), but here is the output of that script, run from within VSCode with the problematic python environment selected: (Note I've removed a couple of corporate entries I do not want to share, but which I am quite sure are irrelevant.) Run from within VSCode |
|
One of the differences between b11 and b12 was that we started to enable Qt support by default - it used to be effectively "none", now it's "auto". And the way pydevd handles "auto" is by probing a bunch of different imports one by one, if I remember correctly? So perhaps in this case that causes an incorrect version to load? |
|
Would it make sense to break out this probing code into a separate script that I could run locally and see where it fails? I'm presuming there's something in my environment that it is objecting to and knowing what that is might be useful. |
|
Here's what it does: debugpy/src/debugpy/_vendored/pydevd/_pydev_bundle/pydev_monkey_qt.py Lines 39 to 58 in 44b01c8 To compare with ArcGIS default environment, it would be interesting to see what |
|
In my case, qt_support_mode == 'pyqt5' prints: |
|
This is strange - if it's set to "pyqt5", it means that it had successfully imported What does |
|
Also, for a slightly more readable output for the module list: for name in sorted(sys.modules): print(name, "\n\t", sys.modules[name]) |
|
The above was run from within VSCode using the debug function. When I run from python directly in the environment, I get this (showing the presence of pyqt5) I admit I don't fully understand which environments VSCode uses and when; sometimes I have warnings that modules don't exist, but the code runs fine, proving that they do. |
(run from inside VSCode) |
|
I was thinking that it should be possible to have native thread detection when running in the frame eval mode. In this case, on frame eval mode (so, only Python 3.6 onwards with compiled extensions available), we actually have a hook that doesn't require the tracing -- and where we could enable tracing for untraced threads (in which case the qt patching wouldn't be needed in the first place). I'll investigate to see if this is actually feasible. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Environment data
Actual behavior
When firing up the debugger (F5) even a simple one-line script (print("hello")), I get the dreaded "timed out waiting for debuggee to spawn" dialog. I can run the script using the green triangle with the same version/environment, and if I select a different version of Python, the debugger works fine.
Everything consistently worked for months until this morning when VSCode updated to the June version, and debugging stopped working.
Expected behavior
Debugging should work.
Steps to reproduce:
Press F5 to debug current program.
I've read some of the past cases for this issue, and followed some of the suggestions, but they didn't really seem relevant. I'm not even sure this is a ptvsd issue, but all searches on the error message led me here.
The text was updated successfully, but these errors were encountered: