Error message if subprocess exits before attach to it completes

[noymer]

I post this from the issue: microsoft/vscode-python#12481 (comment)

Environment data

• debugpy version: 1.0.0b11
• OS and version: Windows_NT x64 10.0.17763
• Python version (& distribution if applicable, e.g. Anaconda): 3.6.7
• Using VS Code or Visual Studio: VS Code
  • VS Code version: 1.46.1 (user setup)
  • commit: cd9ea6488829f560dc949a8b2fb789f3cdc05f5d
  • use remote WSL: Ubuntu-18.04

Actual behavior

After running python debug execution, Server[6] disconnected unexpectedly Server[pid=5450] disconnected unexpectedly appear.
(It's after finishing the code, so I can use remote debugging)

Expected behavior

There is no error

Steps to reproduce:

code with multiprocessing

try_multiprocess.py

from multiprocessing import Pool
import debugpy

print(debugpy.__version__)

def f(x):
    return x*x

if __name__ == '__main__':
    with Pool(5) as p:
        print(p.map(f, [1, 2, 3]))

launch.json

        {
            "name": "try multiprocess",
            "type": "python",
            "request": "launch",
            "program": "${workspaceFolder}/try_multiprocess.py",
            "console": "integratedTerminal",
            "justMyCode": false,
        }

Push the debug execution button on VS Code, and the code itself works properly, but the errors
Server[6] disconnected unexpectedly Server[pid=5450] disconnected unexpectedly appear.

$  cd /home/noymer/program/sandbox ; env /usr/bin/python3 /home/noymer/.vscode-server/extensions/ms-python.python-2020.6.89148/pythonFiles/lib/python/debugpy/launcher 57561 -- /home/noymer/program/sandbox/try_multiprocess.py 
1.0.0b11
[1, 4, 9]

[fabioz]

I can reproduce this.

The error doesn't always happen -- sometimes it works, sometimes it fails in the way described and sometimes it fails with a different error:

If I set the debugAdapterPath to use the dev version it always works (I tried using different release tags and couldn't make it fail).

Those messages seem to be originated in the following places:
https://github.com/microsoft/debugpy/blob/v1.0.0b11/src/debugpy/adapter/components.py#L105
https://github.com/microsoft/debugpy/blob/v1.0.0b11/src/debugpy/adapter/clients.py#L458

And it really seems like they should be ignored (i.e.: subprocesses can be killed before being able to connect to it or even while the connection is being done, which seems like the case here as the multiprocessing Pool is killed sometimes after creating all the processes requested and sometimes earlier, while it's still creating processes).

I'm not sure why setting the debugAdapterPath makes those errors be ignored (maybe the client itself goes through some different path?)

@int19h since this is all in the adapter (and maybe in the interaction with VSCode itself), would you like to take a look at that?

[int19h]

The difference with "debugAdapterPath" is probably due to lack of native tracing slowing things down enough that it doesn't happen. I couldn't repro it so far either with or without.

The first error ("disconnected unexpectedly") is in the code that handles failures for all message handlers in the adapter, on the basis that most of them involve at least one, and often several, messages sent to the server. It's not easy to get rid of, because the client expects some response at that point, and an error response is really the only one that's generic enough to apply to any request. But, the error response for the "attach" request always produces a visible error message...

It looks like the "attach" handler needs to do more specific handling in case of subprocesses - if it runs into either of those errors, it should basically pretend that attach succeeded, but the process then terminated immediately - this would be rather convoluted, because of all the "configurationDone" logic that's shared with launch. But perhaps it can get away with no response, and a "terminated" event.

[int19h]

Sending "terminated" before responding to "attach" is slightly better - VSCode will still complain, but now it's a pop-up notification ("failed to start debug session") instead of a modal box.

Sending a dummy success response to "attach" proved to be easier than I thought, and provides the smoothest UX.