Subprocesses not reported to client in virtualenv

[int19h]

This is specific to Python 3.7+ on Windows, when code is running from a virtual environment, and uses sys.executable to spawn a subprocess.

The underlying cause is the same as in microsoft/ptvsd#1930: sys.executable points to a stub binary that spawns the actual Python interpreter, and so when the subprocess spawns and connects to the debug adapter, its parent PID is the stub. But the adapter needs to know the actual parent PID to determine which debug session to send the "debugpyAttach" event to - and if it can't find a session matching that PID, it doesn't send the notification at all. Meanwhile, the subprocess remains in suspended state, waiting for something to attach to it.

[int19h]

It feels like the most reliable way to handle this is to have pydevd report the PID of the process where it detoured the spawn. Currently, the adapter gets "pid" and "ppid" from "pydevdSystemInfo" response, and pydev provides "ppid" by calling os.getppid(). But since it knows the identity of the spawning process in monkey-patched CreateProcess call, it could pass the PID to pydevd in the subprocess using a command line argument; and that could then be reported as another property in system info. That would then give the adapter a reliable way to build the parent/child tree for all subprocesses, regardless of the presence of any stubs etc. @fabioz, what do you think?

Regardless of that, though, the code that's handling subprocess connections should be more graceful when the parent PID doesn't match anything. Not reporting the subprocess at all is a bad way to handle it, because the subprocess is then prevented from running any code, with no way to unblock it. It should instead report the subprocess as belonging to the first (root) process in the session; and if that one is gone, then pick some process at random. The process tree in the IDE will not be correct in all cases, but at least the process will be debugged instead of getting stuck.

[fabioz]

@int19h I think it should be straightforward to provide the ppid as the initial launcher pid in pydevd (instead of the real ppid), so, I'll take a look at that.