Attachment fails on Node 8

[dlgenterprises]

• VSCode Version: 1.47
• OS Version: OSX 10.15.5

Steps to Reproduce:

1.Run app and first thing I notice is console.log doesn't show their usual messages. In my app usually 2 messages show up, "Express running on port 3000", and "Settings updated..." They no longer appear.
2.Run app and I notice that all the break points I set turned to hollow circles, and they do not stop when the code is executed. You can see the screen shot where the break point has turned to a hollow circle. Hovering over the break point says, "Unbound breakpoint".
3. These issues only started after I was automatically updated to 1.47 today.

Does this issue occur when all extensions are disabled?: Yes/No (don't know, I tried running this and got "zsh: command not found: code"

[connor4312]

Can you please collect a trace log using the following instructions?

If you're able to, add "trace": true to your launch.json and reproduce the issue. The location of the log file on your disk will be written to the Debug Console. Share that with us.

⚠️ This log file will not contain source code, but will contain file paths. You can drop it into https://microsoft.github.io/vscode-pwa-analyzer/index.html to see what it contains. If you'd rather not share the log publicly, you can email it to connor@xbox.com

/needsMoreInfo

[dlgenterprises]

I'm sorry, I don't know what else to report. w/o Debugging and console.log, VS Code is almost useless to me. I don't know what else you need. I did a trace and sent that to the address above.

[connor4312]

Just got the emailed logs. It looks like we aren't able to attach a websocket to the launched process, so indeed nothing will work. This is a new issue to me.

I've created a build with additional logging, if you could run it and the complete output that would be superbly useful. (Our normal logs here aren't sufficient, since we can't attach to the process to get them.)

1. Download https://memes.peet.io/img/js-debug-issue-102166.vsix
2. Run the "Install from VSIX" command on the command palette (ctrl+shift+p)
3. Important set "console": "integratedTerminal", in your launch config (or the logs will not be visible)
4. Run it and copy the output

Until we get this fixed, you can use the old debugger by setting debug.javascript.usePreview: false in your user settings.

Thanks very much for your help with diagnosing this 🙂

[dlgenterprises]

Thanks,
Here's the output from that:
env NODE_ENV=development 'NODE_OPTIONS=--require /Users/jesse/.vscode/extensions/ms-vscode.js-debug-1.47.3/src/bootloader.bundle.js ' 'VSCODE_INSPECTOR_OPTIONS={"inspectorIpc":"/var/folders/9j/jnp0yfj54qv7xfppngpct51m0000gn/T/node-cdp.37391-2.sock","deferredMode":false,"waitForDebugger":"","execPath":"/usr/local/bin/node","onlyEntrypoint":false,"fileCallback":"/var/folders/9j/jnp0yfj54qv7xfppngpct51m0000gn/T/node-debug-callback-043a9829e3f84437"}' /usr/local/bin/node ./app.js
jesse@Utopia-Planitia nms-sadd % env NODE_ENV=development 'NODE_OPTIONS=--require /Users/jesse/.vscode/extensions/ms-vscode.js-debug-1.47.3/src/bootloader.bundle.js ' 'VSCODE_INSPECTOR_OPTIONS={"inspectorIpc":"/var/folders/9j/jnp0yfj54qv7xfppngpct51m0000gn/T/node-cdp.37391-2.sock","deferredMode":false,"waitForDebugger":"","execPath":"/usr/local/bin/node","onlyEntrypoint":false,"fileCallback":"/var/folders/9j/jnp0yfj54qv7xfppngpct51m0000gn/T/node-debug-callback-043a9829e3f84437"}' /usr/local/bin/node ./app.js
Debugger listening on ws://127.0.0.1:49851/28d87e18-a82b-4dad-98a0-a3d7f4842037
For help see https://nodejs.org/en/docs/inspector
ℹ info Received attach for target
ℹ info Attaching to target at ws://127.0.0.1:49851/28d87e18-a82b-4dad-98a0-a3d7f4842037
ℹ info Checking for loopback address
ℹ info Is loopback? true
ℹ info Created websocket object, waiting for open true
Debugger attached.
body-parser deprecated undefined extended: provide extended option app.js:33:20
Express server listening on port 3000 at 07/10/2020 06:55 PM
Setting changes complete.
GET /admin/manage?=1594421355679 200 231.343 ms - 6392
GET /admin/faqs?=1594421355680 200 171.552 ms - 11508
GET /admin/editfaqitem/8?_=1594421355681 200 109.254 ms - 3778
POST /admin/savefaqitem/8 500 18.643 ms - 254

[connor4312]

Hm, okay. All our info seems to line up. Node echoes the websocket address, and we start trying to create a websocket connection to it. Node says it attaches the debugger, but the websocket never emits an 'open' or 'error' event.

Is there anything on your machine you suspect could be interfering with network traffic like this? Proxies, antiviruses, etc?

[dlgenterprises]

I do have Bitdefender installed, but I just turned that off and tried it again and that didn't make a difference. To my knowledge there have been no other updates installed today except VS Code 1.47, it was working fine yesterday. BTW, setting debug.javascript.usePreview: false seems to fix the problem.

[dlgenterprises]

I am on a Mac, and I frequently have to turn something on in the Privacy area to allow something to work. I wonder if there is something in that area?

[connor4312]

Ah. Hm. I know bitdefender, at least on Windows, does do request interception. Unsure if turning that off actually turns off interception or just stops filtering data. Although I tried installing the Bitdefender Antivirus trial on OSX Mojave and things still worked. It might be the firewall (togglable in preferences) but again I run with that on without issues.

If you have some time, here's a build of the debugger hardcoded to use port 9229, like the old Node debugger did. Maybe that port is allowlisted somewhere where other random ports are not. If this build does work then we can be quite certain it's something on the network. https://memes.peet.io/img/js-debug-issue-102166-again.vsix

[dlgenterprises]

Ok, I tried that. The output of that is as follows, however, the break point still says "Unbound breakpoint":

env NODE_ENV=development 'NODE_OPTIONS=--require /Users/jesse/.vscode/extensions/ms-vscode.js-debug-1.47.3/src/bootloader.bundle.js ' 'VSCODE_INSPECTOR_OPTIONS={"inspectorIpc":"/var/folders/9j/jnp0yfj54qv7xfppngpct51m0000gn/T/node-cdp.96804-2.sock","deferredMode":false,"waitForDebugger":"","execPath":"/usr/local/bin/node","onlyEntrypoint":false,"fileCallback":"/var/folders/9j/jnp0yfj54qv7xfppngpct51m0000gn/T/node-debug-callback-6c4886b023b53573"}' /usr/local/bin/node ./app.js
jesse@Utopia-Planitia nms-sadd % env NODE_ENV=development 'NODE_OPTIONS=--require /Users/jesse/.vscode/extensions/ms-vscode.js-debug-1.47.3/src/bootloader.bundle.js ' 'VSCODE_INSPECTOR_OPTIONS={"inspectorIpc":"/var/folders/9j/jnp0yfj54qv7xfppngpct51m0000gn/T/node-cdp.96804-2.sock","deferredMode":false,"waitForDebugger":"","execPath":"/usr/local/bin/node","onlyEntrypoint":false,"fileCallback":"/var/folders/9j/jnp0yfj54qv7xfppngpct51m0000gn/T/node-debug-callback-6c4886b023b53573"}' /usr/local/bin/node ./app.js
Debugger listening on ws://127.0.0.1:9229/85880afb-1f05-4a64-aa16-5bd020c72a09
For help see https://nodejs.org/en/docs/inspector
ℹ info Received attach for target
ℹ info Attaching to target at ws://127.0.0.1:9229/85880afb-1f05-4a64-aa16-5bd020c72a09
ℹ info Checking for loopback address
ℹ info Is loopback? true
ℹ info Created websocket object, waiting for open true
Debugger attached.
body-parser deprecated undefined extended: provide extended option app.js:33:20

[connor4312]

Hm. This kind of stumps me. Two more queries you could try:

• Which Node.js version are you using? Perhaps try a different one, if you have nvm/a switcher available.

• After launching it using that hardcoded port, try attaching to that port using an 'attach' type launch config. If this doesn't work, then it's probably something in Node / whatever version of Node you're running.

{
  "type": "node",
  "name": "Test Attach",
  "request": "attach",
  "address": "127.0.0.1",
  "port": 9229,
}

• If you have can easily run the code on another machine/vm, try doing the same thing there. If that also fails it means it might be 'something' in how your app or launch is set up...

I really appreciate your help and willingness to diagnose this!

[connor4312]

Whoops, didn't mean to hit the close button

[bodrovphone]

Thank you @dlgenterprises ,
having "debug.javascript.usePreview": false setting helped perfectly!

[dlgenterprises]

I'm using Node version 8.16.2
I have another Mac, but other than being older, it's virtually identical, it's running same version of the OS and everything. However, it was running VS Code version 1.42, and the debugger ran just fine in it, but after restarting VS Code, it had been updated to 1.47, and the debugger doesn't run on that Mac either.

As for "...try attaching to that port using an 'attach'...", I'm not very clear on what you want me to do there. Am I modifying my existing launch.json some way, or creating a new Launch, or doing something else?

[connor4312]

Ahh, that's the key! I was able to reproduce running that version of Node as well. I should be able to have a fix for it shortly.

Also, just in case you didn't know, Node 8 is EOL as of April. If there's nothing keeping you there, updating to Node 14 gets you lots of nice new features and performance 🙂

[dlgenterprises]

We have several old node modules that we rely on that won't run in anything newer than 8. We know that is a problem, and we will have to look for some alternatives at some point, but that's the only thing keeping us in Node 8 for now. Thanks, though and this just gives us another reason to start looking more quickly for an alternative.

[connor4312]

Update: these fixes have been released in VS Code 1.47.2. If you're running into an issue running your Node 8 app, you only need to update VS Code 🙂

Fixed in the linked commit.

How can you fix your debugging? Either:

1. Update to Node 10 or higher
2. Use the latest nightly build
3. Wait until early Thursday the 16th when these changes are released in the recovery
4. Use debug.javascript.usePreview: false to temporarily use the old debugger, at least until (3) happens

What happened? We used Promise.finally in some timeout-related code. This was undefined on Node 8, and crashes the watchdog process responsible for setting up communication between your program and VS Code.

Why did it happen? We're aware that some code will run in the user's Node version, and we have our TypeScript options set for that -- targeting ES2017 in our lib and target parameters, which is advertised to map to Node 8. However, Promise.finally was present in those typings, even though Node 8 didn't have it.

How can we prevent this? Our test suite runs against Node 12 -- previous version of Node don't have some features that we (optionally) need to build and test new features. I've now added an additional 'minspec' build that runs select tests against Node 8 to ensure sanity https://dev.azure.com/vscode/VS%20Code%20debug%20adapters/_build/results?buildId=48413&view=logs&j=a8e58cb5-ff8c-58f5-08fa-0c710542c7b6

Longer term we will need a policy around what versions of Node we support. In js-debug we dropped support for versions <7, since they run an entirely different protocol. Going forward, what should we do -- match Node LTS? LTS + 1 year? Or usage based.

[sreed4]

1.47 and node 12.8.1 will
not use breakpoints. Same as others, set the break point, when start debug the breakpoint is unbound.

[connor4312]

@sreed4 please collect a trace log using these instructions:

If you're able to, add "trace": true to your launch.json and reproduce the issue. The location of the log file on your disk will be written to the Debug Console. Share that with us.

⚠️ This log file will not contain source code, but will contain file paths. You can drop it into https://microsoft.github.io/vscode-pwa-analyzer/index.html to see what it contains. If you'd rather not share the log publicly, you can email it to connor@xbox.com

[connor4312]

@sreed4 thanks for the log!

It looks like you have outFiles set to ${workspaceFolder}/dist. However, this is a glob pattern, so that alone doesn't match files/doesn't recurse. You probably want ${workspaceFolder}/dist/**/*.js

[connor4312]

A fix for this issue has now been released in VS Code 1.47.2. If you previously had to opt-out of the new debugger, you should be safe to turn it back on. Thanks again for the report!