"launch" doesn't work with venv on Windows and Python 3.7+

[vdurante]

Environment data

• VS Code version: 1.40.1
• Extension version (available under the Extensions sidebar): 2019.11.49689
• OS and version: Windows 10 Pro 1909
• Python version (& distribution if applicable, e.g. Anaconda): 3.7.4
• Type of virtual environment used: pipenv or poetry. Happens on both

Expected behaviour

Being able to debug the application

Actual behaviour

Popup shows message Session-1 timed out waiting for debuggee to spawn (debugee as it is written)

I have also noticed an odd behavior. Testing on 2 machines with the same setup, the terminal command for running the same program runs very differently.

Machine with the issue:

(.venv) PS C:\Repos\NMIND\CCP\transport\ccp-etl-adlib> & 'c:\Repos\NMIND\CCP\transport\ccp-etl-adlib\.venv\Scripts\python.exe' 'c:\Users\dudut\.vscode\extensions\ms-python.python-2019.11.49689\pythonFiles\lib\python\new_ptvsd\wheels\ptvsd\launcher' 'C:\Repos\NMIND\CCP\transport\ccp-etl-adlib/main.py'

Machine without the issue:

(.venv) PS C:\Repos\NMind\CCP\transport\ccp-etl-adlib> cd 'c:\Repos\NMind\CCP\transport\ccp-etl-adlib'; ${env:PYTHONIOENCODING}='UTF-8'; ${env:PYTHONUNBUFFERED}='1'; & 'c:\Repos\NMind\CCP\transport\ccp-etl-adlib\.venv\Scripts\python.exe' 'c:\Users\vitco\.vscode\extensions\ms-python.python-2019.11.49689\pythonFiles\ptvsd_launcher.py' '--default' '--client' '--host' 'localhost' '--port' '64361' 'C:\Repos\NMind\CCP\transport\ccp-etl-adlib/main.py'

Steps to reproduce:

Even the simplest program wont debug if it is running from a virtual environment.
Tried with or without activation.
Tried running on CMD or PS.
Tried running on integratedTerminal, externalTerminal, internalConsole.
Tried running on poetry and pipenv.
Reinstalled python and extension. Cleared all python, pipenv, virtualenv, poetry, and extension files and folders across the computer.
All combinations failed.

Logs

terminal.txt
settings.json
launch.json
ptvsd.launcher-7012.log
ptvsd.adapter-8744.log
debugger.vscode_482d787f-1202-4275-ad01-2e93f7e025ed.log
ptvsd.server-13056.log

[int19h]

The difference in command line indicates that one environment is using ptvsd 4.x, and the other one is 5.x.

[int19h]

Do you see this working correctly if a virtual environment is not used?

[int19h]

Ah, I think I see what the issue is.

I+00000.375: /handling #2 request "launch" from IDE[1]/
             Waiting for connection from debug server with PID=2524...

I+00001.094: Accepted incoming Connection connection from 127.0.0.1:51137.

D+00001.094: Starting message loop for channel Server[?]

D+00001.094: Server[?] <-- {
                 "seq": 1,
                 "type": "request",
                 "command": "pydevdSystemInfo"
             }

D+00001.110: Server[?] --> {
                 "pydevd_cmd_id": 502,
                 "seq": 2,
                 "type": "response",
                 "request_seq": 1,
                 "success": true,
                 "command": "pydevdSystemInfo",
                 "body": {
                     "python": {
                         "version": "3.7.4final0",
                         "implementation": {
                             "name": "cpython",
                             "version": "3.7.4final0",
                             "description": "CPython"
                         }
                     },
                     "platform": {
                         "name": "win32"
                     },
                     "process": {
                         "pid": 13056,
                         "ppid": 2524,
                         "executable": "C:\\Repos\\NMIND\\CCP\\transport\\ccp-etl-adlib\\.venv\\Scripts\\python.exe",
                         "bitness": 32
                     }
                 }
             }

The adapter is expecting the connecting debug server to has PID=2524, because that's the PID of the process that it spawed. Instead, it gets a connection from PID=13056, which is a child of 2524.

This happens because on Windows, starting with Python 3.7.2, venv now uses a lightweight stub for python.exe, which spawns the actual python.exe from the base interpreter as a child.

[vdurante]

I will answer all 3 of your messages

1. ok, that makes sense. Thank you
2. yes. Everything works fine without environment. And the environments stopped working randomly. Environments were working yesterday
3. I understood your description, but couldn't understand if this is a bug or something I did wrong

Thank you for the fast response

[int19h]

You did nothing wrong - this is definitely a bug, and a high-priority one at that - so a fix will be coming soon. The comment was there to record the results of the preliminary investigation.

Thank you for bringing it to our attention, and for the logs that allowed it to be diagnosed so quickly!

[vdurante]

Thank you very much @int19h. I am glad I could help.

[siben168]

i saw this ticket has been closed, but how can i get updated on VS Code? I am using the latest Code but this issue still exists.

Thanks

[karthiknadig]

@siben168 Try the insiders build of the extension: https://pvsc.blob.core.windows.net/extension-builds/ms-python-insiders.vsix . Tonight's build has the debugger with the fix.

[siben168]

@karthiknadig great! it works for me, thank you so much.

[dwaynewei]

hey guys, I got a similar issue. and I got no answers while googled it. pls help me if any of you guys knows how to solve it. thx a lot.

[karthiknadig]

@dwaynewei Can you file a separate bug? It is likely that you are running into microsoft/vscode-python#10843 but we will need more data.

[int19h]

@dwaynewei, what you're seeing is a different issue: microsoft/debugpy#84 - we're still working on it.