Extension host did not start in 10 seconds, it might be stopped on the first line and needs a debugger to continue.

[lhton74]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.63.2
• OS Version: Linux x64 4.18.0-348.2.1.el8_5.x86_64

Other info:

Commit: 899d46d
Date: 2021-12-15T09:39:46.686Z
Electron: 13.5.2
Chromium: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0

Steps to Reproduce:

1. Follow "yo code" to set up vanilla Typescript extension (https://code.visualstudio.com/api/get-started/your-first-extension).
2. Run Extension (F5)

Same symptom as issue #20581. The extension host starts in a new window and listens on a port, but the debugger is never able to connect:

Executing the following command on the terminal shows that the process is indeed listening on that port:

$ lsof -i :53931
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
code 4085305 lhton 43u IPv4 216710607 0t0 TCP localhost:53931 (LISTEN)

I was able to generate a log file by adding "trace": true to the launch.json, then import that file into https://microsoft.github.io/vscode-pwa-analyzer/index.html. The first error that showed up was:

"root":{5 items
"tag":"runtime.launch"
"timestamp":1641949900471
"message":"Error looking up /json/version"
"metadata":{4 items
"ok":false
"body":"connect ECONNREFUSED ::1:53931"
"statusCode":503
"error":{2 items
"message":"Unexpected 503 response from http://localhost:53931/json/version: connect ECONNREFUSED ::1:53931"
"stack":"Error: Unexpected 503 response from http://localhost:53931/json/version: connect ECONNREFUSED ::1:53931 at b.fetchHttp (/usr/share/code/resources/app/extensions/ms-vscode.js-debug/src/extension.js:2:1146792) at runMicrotasks (<anonymous>) at processTicksAndRejections (internal/process/task_queues.js:93:5) at b.fetchJson (/usr/share/code/resources/app/extensions/ms-vscode.js-debug/src/extension.js:2:1145926) at async Promise.all (index 0) at l (/usr/share/code/resources/app/extensions/ms-vscode.js-debug/src/extension.js:2:1397969) at Object.retryGetNodeEndpoint (/usr/share/code/resources/app/extensions/ms-vscode.js-debug/src/extension.js:2:1398771) at f.launchProgram (/usr/share/code/resources/app/extensions/ms-vscode.js-debug/src/extension.js:2:1414411) at f.launch (/usr/share/code/resources/app/extensions/ms-vscode.js-debug/src/extension.js:2:1438435) at t.Binder.captureLaunch (/usr/share/code/resources/app/extensions/ms-vscode.js-debug/src/extension.js:2:1230057) at t.Binder._launch (/usr/share/code/resources/app/extensions/ms-vscode.js-debug/src/extension.js:2:1229602) at async Promise.all (index 1) at t.Binder._boot (/usr/share/code/resources/app/extensions/ms-vscode.js-debug/src/extension.js:2:1228654) at t.default._onMessage (/usr/share/code/resources/app/extensions/ms-vscode.js-debug/src/extension.js:2:1321495)"
}
}
"level":0
}

It looks like the debugger did a fetchHttp() to "http://localhost:53931/json/version" and failed. The funny thing is, when I enter this URL in a local Firefox browser, I get what looks like the correct response:

{
"Browser": "node.js/v14.16.0",
"Protocol-Version": "1.1"
}

Other notes:

• This works when I try it locally on my MacOS (locally, not using remote-ssh). Something about running it on the Linux Centos8 VM prevents it from working.
• The Linux VM is behind a corporate firewall. Not sure if that makes a difference.

Further debugging notes:

• Using the Rest Client extension in my VS Code, I tried sending the "http://localhost:53931/json/version" request. It failed. But interestingly, I then tried sending "http://127.0.0.1:53931/json/version" and it succeeded! So maybe something about the "localhost" name resolution?

[lhton74]

I think what might be happening is that the VS code extension host is listening on an IPv4 address. The debugger attempts to connect to it using "http://localhost:53931/json/version" and fails because on my Linux VM, "localhost" resolves to an IPv6 address.

Is there a way to make the VS code debugger connect using "http://127.0.0.1:53932/..." instead of "localhost"?

[lhton74]

I think the extension host needs to be fixed to listen on "localhost" instead of 127.0.0.1 (an IPv4 address). I haven't looked at the VS Code source code around this area, but that would be the potential fix.

[weinand]

@connor4312 the IP4/IP6 observation sounds like a reasonable explanation for the problem.
Is there a workaround or do we have to change VS Code to use "localhost" instead of 127.0.0.1?

[connor4312]

I've actually seem this problem crop up a few times on Linux. For example, there are users whose development servers listen on 127.0.0.1 and they connect at localhost in their browser. Browsers seem to solve for this, as @lhton74 discovered, but if users enter the wrong address in their debug configs then we can't do things like look up sourcemaps from the server.

So I think what I'll do is, if localhost is given as the hostname, have js-debug automatically fall back to 127.0.0.1 on failure.

We can also have VS Code listen on localhost by default, I think that's appropriate.

[connor4312]

@lhton74 please try out the next nightly release and let us know if it's fixed for you. Thanks for the detailed issue and self-debugging 🙂

[lhton74]

Thanks all for the quick responses!

I have had other problems recently such as breakpoints in Typescript code not being able to bind. I wonder if they are related? It would seem to me that if 127.0.0.1 instead of localhost is used anywhere in the VS Code source code, it could potentially cause this issue on a server that resolves localhost to IPv6.

There doesn't seem to be a workaround now, so I will try the next nightly release as instructed.

Thanks again!

[lhton74]

Hi @connor4312. I tried again using the nightly release. The debugger still failed to connect to the extension host. Once again, I generated the debug log file:

vscode-debugadapter-f7ae5530.json.gz

and analyzed it using https://microsoft.github.io/vscode-pwa-analyzer/index.html. It appears that ECONNREFUSED status code 503 has gone away, suggesting that your recent fix got us a bit further. However, the "cdp.send attachToTarget" message never gets a reply. I compared this with the working test case running on my local MacOS, and in that case the "cdp.send attachToTarget" message gets an immediate "cdp.receive" reply with a valid "sessionId".

Do you have any idea why this attach mechanism is still not working? How should I debug this issue further?

Here's the result of the vscode-pwa-analyzer from the failing case (running local on my Linux VM):

[connor4312]

Moved discussion to new issue, marking this as a dupe so that the other can be verified