Support Node debug protocol autodetection alongside dynamically putting proc into debug mode

[roblourens]

I need to support "processId": "${command:PickProcess}" in a launch config for the 'inspector' protocol. In Node 8, when a SIGUSR1 signal is sent to the process, it will be in debug mode for the inspector protocol instead of the legacy protocol.

Currently, startSession does protocol detection for attach, then picks the debug adapter, then the command:PickProcess variable is resolved to execute the PickProcess command. Then the debug adapter sees the PID and sends the signal to put it into debug mode. We need to flip this around so that the process can be put into debug mode, then the protocol detected, so the adapter can be selected.

One possibility:

1. startSession, when detecting the protocol for 'attach', checks processID, and resolves the command variable manually to run the PickProcess command, instead of letting vscode do it
2. PickProcess runs, then we send the SIGUSR1 signal to that PID. We can't pick the port in this case.
3. Then we do protocol detection. We try each default port, not knowing whether it actually belongs to the PID in question.
   ~ Or, we need the user to know which port will be used. But in that case, they may as well just set 'protocol' too because the two are dependent. (Or we look at port number to assume which protocol, instead of autodetect)
4. Continue as usual

That's not totally satisfactory because of the slim chance of attaching to the wrong process, or requiring the user to set the port. It's maybe the best we can do. Thoughts @weinand, @isidorn?

[roblourens]

We may be able to use netstat to determine which port a PID is listening on. Which would be great, because we wouldn't have to do protocol detection at all, we can just check the port number.

[roblourens]

It looks like we could solve step 3 above for all platforms

• Windows - netstat -ano, find line with pid and port number
• MacOS/Linux - lsof -i or -p, I can't figure out how to get PID out of netstat

Thoughts @weinand?

[weinand]

@roblourens yes, using lsofor netstat sounds interesting and we should try to use this approach in May.

(And I've already learned two things:

• the launch config passed to the startSession command still has the unsubstituted variables (which makes sense, but surprised me).
• lsof can only find those node processes that were already launched with the --debug or --inspect flags and are already listening on the debug port. If node was started without debug arguments, lsof doesn't help (I tried to replace the code in the process picker that relies on hardcoded process names by code that looks for processes that have a specific port open, but that failed of course...)