Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Port 9229 in use by VS Code #85328

Closed
ejizba opened this issue Nov 21, 2019 · 10 comments
Closed

Port 9229 in use by VS Code #85328

ejizba opened this issue Nov 21, 2019 · 10 comments
Assignees
Labels
bug Issue identified by VS Code Team member as probable bug candidate Issue identified as probable candidate for fixing in the next release extension-host Extension host issues verified Verification succeeded

Comments

@ejizba
Copy link

ejizba commented Nov 21, 2019

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 #73818 (an older issue specific to nodemon - @weinand recommended creating a new issue) and MicrosoftDocs/azure-docs#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 #73818 (comment):

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 #73818 (comment):

I tried to trace code in developer tool. I found that I might be triggered by this line:

const port = await this._extensionService.getInspectPort(true);

And followed by

await this._extensionHostProcessWorker.enableInspectPort();

Here is the related change:
0f2cda1

@roblourens
Copy link
Member

Have you been debugging extension tests? Could be related to #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.

@ejizba
Copy link
Author

ejizba commented Nov 21, 2019

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 MicrosoftDocs/azure-docs#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 weinand self-assigned this Nov 22, 2019
@weinand weinand added the debug Debug viewlet, configurations, breakpoints, adapter issues label Nov 22, 2019
@weinand
Copy link
Contributor

weinand commented Nov 22, 2019

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.

@weinand weinand assigned jrieken and unassigned weinand Nov 22, 2019
@weinand weinand removed the debug Debug viewlet, configurations, breakpoints, adapter issues label Nov 22, 2019
@jrieken jrieken added the extension-host Extension host issues label Nov 22, 2019
@jrieken
Copy link
Member

jrieken commented Nov 22, 2019

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?

@jrieken jrieken closed this as completed Nov 22, 2019
@jrieken jrieken added this to the November 2019 milestone Nov 22, 2019
@anthonychu
Copy link
Member

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 roblourens added bug Issue identified by VS Code Team member as probable bug candidate Issue identified as probable candidate for fixing in the next release labels Nov 22, 2019
@roblourens roblourens reopened this Nov 22, 2019
@roblourens
Copy link
Member

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.

1 similar comment
@roblourens
Copy link
Member

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
Copy link

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
Copy link
Member

Can you check which process is using 9229?

@deepanjannag
Copy link

Can you check which process is using 9229?

netstat didnt return anything on 9229

@vscodebot vscodebot bot locked and limited conversation to collaborators Jan 8, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Issue identified by VS Code Team member as probable bug candidate Issue identified as probable candidate for fixing in the next release extension-host Extension host issues verified Verification succeeded
Projects
None yet
Development

No branches or pull requests

7 participants