Vscode: Port 9229 in use by VS Code

[EricJizbaMSFT]

We've had a lot of users run into issues where VS Code (likely the extension host process) is hanging on to port 9229 which means they fail to debug node projects. Users consistently say it repros on v1.40.1, but does _not_ repro if they downgrade to v1.39.2. Most of the existing user reports come from https://github.com/microsoft/vscode/issues/73818 (an older issue specific to nodemon - @weinand recommended creating a new issue) and https://github.com/MicrosoftDocs/azure-docs/issues/42379.

I have not personally reproduced this issue, but @jeffhollan @eduardolaureano @anthonychu have all hit it and can hopefully give more detail if necessary. I've also cherry-picked a few comments below which seem particularly relevant:

_originally posted by @Yukaii in https://github.com/microsoft/vscode/issues/73818#issuecomment-553318646_:

Run attach to process and show the error.

Look up the occupied port with lsof command:

lsof -i :9229

COMMAND     PID  USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
Code\x20H 20544 yukai   48u  IPv4 0xxxxxxxxxxxxxxxxx      0t0  TCP localhost:9229 (LISTEN)

And found that extension host process is listening to the port 9229

Applications/Visual Studio Code.app/Contents/Resources/app/out/bootstrap-fork --type=extensionHost

_originally posted by @hermanho in https://github.com/microsoft/vscode/issues/73818#issuecomment-555814237_:

I tried to trace code in developer tool. I found that I might be triggered by this line:
https://github.com/microsoft/vscode/blob/4934a6f487b9ed6b99b900ae0710c7b452792e20/src/vs/workbench/contrib/extensions/electron-browser/extensionsAutoProfiler.ts#L46

And followed by
https://github.com/microsoft/vscode/blob/0f2cda10da1e80088ad7908ac0f743c8f2132de0/src/vs/workbench/services/extensions/common/extensionHostProcessManager.ts#L244

Here is the related change:
https://github.com/microsoft/vscode/commit/0f2cda10da1e80088ad7908ac0f743c8f2132de0

[roblourens]

Have you been debugging extension tests? Could be related to https://github.com/microsoft/vscode/issues/81397

But can you expand more on the actual issue? Debugging node uses a random port by default and shouldn't be blocked by this.

[EricJizbaMSFT]

Have you been debugging extension tests? Could be related to #81397

I work mostly on the Azure Functions extension and we're having plenty of users reports this as mentioned in https://github.com/MicrosoftDocs/azure-docs/issues/42379. I doubt those people are developing extensions for VS Code, let alone running extension tests.

But can you expand more on the actual issue? Debugging node uses a random port by default and shouldn't be blocked by this.

The issue is that some part of VS Code is using port 9229 when it shouldn't be. Default debugging might use a random port, but 9229 is still the default port used for node inspect and so I think a lot of other scenarios are affected. For example Azure Functions debugging always uses 9229. This was not a problem in v1.39 and now it's a problem in 1.40

[weinand]

With the change mentioned above we start the inspect protocol on the extension host process as soon as we detect that the process has become unresponsive. This is done because via the inspect protocol VS Code can better analyse what's going on in the extension host process.

By default the extension host process is not listening for the inspect protocol (so no inspect port is open by default). To enter inspect mode VS Code sends signal SIGUSR1 to the extension host process which will open the default inspect port 9229.

From that moment on, inspect port 9229 is no longer available for other node.js processes. So if your node.js debugging relies on the default port 9229 (e.g. by using a --inspect from the command line), starting up your program will fail with the message Starting inspector on 127.0.0.1:9229 failed: address already in use.

We are planning to fix this problem by making VS Code use a random free port for inspecting the extension host process.

Until we've fixed this, a simple workaround exists: just don't rely on the default port 9229 for your node.js debugging, e.g. specify a port yourself: --inspect=5555 or let node.js pick a random port with --inspect=0. In addition if you let VS Code launch your program, it will pick and manage a random free port automatically, so it should not collide with port 9229 used by VS Code.

---

Configuring node.js to use a random port when a SIGUSR1 signal is received can be done via this argument: --inspect-port=0.

[jrieken]

Extension host profiling now uses a random port which means it very likely doesn't conflict with the default port 9229 anymore. If you are affected by this, the use next insiders or the workaround described above.

@EricJizbaMSFT This process should only kick in when the extension host freezes for a few seconds and this is usually a sign of extensions using much CPU cycles. Does this rings a bell? Did you receive reports in that direction before?

[anthonychu]

If you're running into this while debugging Azure Functions, the workaround is to update the debug port to something other than 9229 in your .vscode/launch.json.

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Attach to Node Functions",
            "type": "node",
            "request": "attach",
            "port": 19229,
            "preLaunchTask": "func: host start"
        }
    ]
}

[roblourens]

Verification steps:

Have an extension with something like

vscode.commands.registerCommand('extension.helloWorld', () => {
    while (true) { }
});

Run the command and the EH should stop responding. After a few seconds, check the devtools console, and you should see the port that the EH is listening on. It would have been 9229 before, and should be something else now.

[roblourens]

Verification steps:

Have an extension with something like

vscode.commands.registerCommand('extension.helloWorld', () => {
    while (true) { }
});

Run the command and the EH should stop responding. After a few seconds, check the devtools console, and you should see the port that the EH is listening on. It would have been 9229 before, and should be something else now.

[deepanjannag]

I'm not sure the issue has been resolved.
When I create a Node powered Azure Function in VS Code and try to run, I get:

A host error has occurred during startup operation '7ccc4111-b0b0-46c7-a1bc-710de30a8d49'.
[2019-11-26 4:22:05 PM] Microsoft.Azure.WebJobs.Script: Object reference not set to an instance of an object.
[2019-11-26 4:22:05 PM] Stopping JobHost
Value cannot be null.
Parameter name: provider
(Cannot connect to runtime process...ECONNREFUSED 127.0.0.1: 9229).

When I change the port in jaunch.json, I get the same error message with the altered port number in the above error message.

[roblourens]

Can you check which process is using 9229?

[deepanjannag]

Can you check which process is using 9229?

netstat didnt return anything on 9229