Debuggers gets attached even when Run without debugging.

[sanandnarayan]

• VSCode Version: 1.47.0
• OS Version: Darwin x64 19.4.0

Version: 1.47.0 Commit: d5e9aa0227e057a60c82568bf31c04730dc15dcd Date: 2020-07-09T08:01:54.115Z Electron: 7.3.2 Chrome: 78.0.3904.130 Node.js: 12.8.1 V8: 7.8.279.23-electron.0 OS: Darwin x64 19.4.0

Steps to Reproduce:

1. Create a new folder.
2. Create a new file index.js with the following contents

   console.log("hi");

3. Click Run -> Run Without Debugging

/Users/anand/.nvm/versions/node/v12.18.0/bin/node /Users/anand/code/playground/temp/vscodetest/index.js
Debugger listening on ws://127.0.0.1:52189/5e1a2214-21b7-46eb-b495-9dc05cb75871
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
Waiting for the debugger to disconnect...
Process exited with code 0

Does this issue occur when all extensions are disabled?: Yes (I have checked in a new insiders build also)

This was not happening 10 hours back. VS code auto updated , and this behaviour propped up. Hence i felt it was a bug with the latest version

https://www.loom.com/share/36ec72a275f544348c1f2fc0944b2a88

[connor4312]

Currently, we will attach the debugger but not enable the "Debugger" domain, among others, in the devtools protocol. This lets you still see the process tree, loaded scripts, and use the repl, but debug-related functionality such as breakpoints/pausing are not available and there's little to no runtime overhead.

• Issue where noDebug was implemented: https://github.com/microsoft/vscode-js-debug/issues/523
• Issue to hide the "Debugger listening" screen cheese: https://github.com/microsoft/vscode-js-debug/issues/558

As mentioned in the linked issue, there's no "spec" within vscode for what exactly noDebug entails, so this seemed like a sensible approach. Open to feedback on it.

[kavika-1]

After accepting the same update a few hours ago, now anything calling node as a means to execute something in the terminal hangs, for instance, grunt dev.

$ grunt dev
Debugger listening on ws://127.0.0.1:34447/b2a12157-4679-4f4a-930b-d75a769794a2
For help, see: https://nodejs.org/en/docs/inspector
^^^^ hangs here waiting for something (but how to prevent this in the first place) ^^^^

Windows 10 2004, WSL 2, Ubuntu 20.04. Remote WSL 0.44.4. /bin/bash -l

All of this has been working great for weeks. And this repros for mocha as well...

Turning off or disabling Debug Auto Attach does not seem to have any effect. But did figured out a short-term workaround is to unset NODE_OPTIONS, but have to track that down in a few places. Plus, lose ability to inspect-brk by removing this.

If it helps, this is the NODE_OPTIONS: --require "/home/david/.vscode-server/data/User/workspaceStorage/524ad04e8e905f63b3e05be24fced37c/ms-vscode.js-debug/bootloader.js"

I have not compared this against the prior vscode release, but will probably downgrade tomorrow and check.

[freddydumont]

Not sure if it's the same issue but I'm getting the same "debugger attached" output simply by launching a terminal. It's even worse if I run any kind of node script:

EDIT: for anyone having the same problem you need to turn off auto-attach in the footer

[albyrock87]

I'm on WSL2 and getting Debugger listening on .... even with Auto Attach: Off.

The terminal starts this way:

That's because in .bashrc I'm using NVM:

It seems that VSCode is attaching to every node process even if auto attach is disabled.

[connor4312]

That screen noise is definitely not great -- issue linked above for that!

@kavika-1 after setting auto attach to disabled, there will be a ⚠️ symbol in the upper right corner of your terminal prompting you to reload it, which is needed to un-set the environment variables.

If you're having trouble with toggling not working, you may be running into this issue (namely if you had previously tried the nightly version of the debugger): https://github.com/microsoft/vscode/issues/98778#issuecomment-649784816

[sanandnarayan]

@connor4312 I am not sure why I dont see a output in the console (when the debugger gets attached). If you see my program is a console.log("hi") program. But when i execute it by clicking the "run without debugging", it does not output anything.

When I go to the terminal and then run it, then it outputs "hi"

[connor4312]

Ah, I missed that amongst everything else. Fixed in the linked commit which will be in the next nightly -- looks like teardown when debugging isn't enabled is (often) too fast that we don't have a chance to send the console message before the session ends.

[connor4312]

A few questions for @kavika-1 / @chasingSublimity, if you know:

1. Did you have auto attach enabled before updating VS Code?
2. Did you ever try to use our preview debugger before? Either by setting debug.node.useV3 or debug.javascript.usePreview
3. When you see it start and 'hang' -- if you open a different folder / workspace in VS Code (ideally a new folder you never opened before) does it happen if you run node there as well?

[kavika-1]

@connor4312 thanks for following-up:

A few questions for @kavika-1 / @chasingSublimity, if you know:

1. Did you have auto attach enabled before updating VS Code? Yes
2. Did you ever try to use our preview debugger before? Either by setting debug.node.useV3 or debug.javascript.usePreview No
3. When you see it start and 'hang' -- if you open a different folder / workspace in VS Code (ideally a new folder you never opened before) does it happen if you run node there as well? Hard to say. I had to downgrade to 1.46 to continue working (and re-install the Remote WSL plugin, which seemed to remove the sticky NODE_OPTIONS when running within vscode). So unfortunately, that i cannot confirm

But I am 99% sure that I exited, wsl --shutdown even rebooted, and so forth after physically removing "debug.node.autoAttach": "on" from both user and project settings. And the hang still happened. PS. would be nice if by default the autoAttach went to user settings, not project settings, when toggled from the command palette.

[connor4312]

Okay, thanks. Fyi you can set debug.javascript.usePreview to false to disable the new debugger which will allow you to stay on 1.47.

[connor4312]

I've updated js-debug to only attach if --inspect is given on the terminal. This will be updated in the next release https://github.com/microsoft/vscode-js-debug/commit/6932b620d6d5ea697a1a1cd00f5bdb07b9167ee6

[kavika-1]

thanks @connor4312 - working with 1.47 again using the debug.javascript.usePreview false

[connor4312]

Further follow up: I have found the root cause that may frequently cause auto attach to not work or get 'stuck' on when working in remote environments (SSH/WSL).

Because of the number of changes coming up here. I will put in a change to revert auto attach to its old behavior in the recovery release, to be remedied and re-enabled in the July release.

[connor4312]

In the recovery release, and the latest Insiders, I have disabled auto attach in the new debugger. There are, quite evidently, some technical and experiential problems with it that we need to evaluate further. This is expected to be released on Thursday the 16th.

If you're plagued by auto attach attaching to things you don't want it to in the meantime, I'd recommend doing one of the following:

1. Turning Auto Attach (setting ID debug.node.autoAttach) to "off" or "disabled.
2. Use the latest nightly extension where we added an options (true by default) to only attach to processes started with --inspect
3. Set debug.javascript.usePreview to turn off the new debugger entirely (if needed)
4. Use VS Code Insiders, or wait until the ~Thursday recovery release.

If you run into an issue where you're 'stuck' in auto attach on OSX/Linux please try the following:

1. Run echo $VSCODE_INSPECTOR_OPTIONS | awk '{if(match($0, /"([^"]+.deferred)"/,m))print m[1]}' | xargs rm (deletes any orphaned 'auto attach socket' from disk)
2. Reload the window
3. Set debug.node.autoAttach to "on". Wait a moment.
4. Set debug.node.autoAttach to "disabled". Wait a moment.
5. Open a terminal and see if you're in a good state

[RyanLamanskyInsite]

@connor4312, continuing from the bug I reported that was closed as a duplicate, our experience is that even with the fixes associated with this issue, performance is still severely degraded in a stock VS Code configuration.

We have a relatively large Webpack dev server + TypeScript project that takes 39 seconds to start using direct command line, but 336 seconds--over 5 minutes--beginning in 1.47 when "Run Without Debugging" is used (1.46 and older had identical performance between direct command line and Run Without Debugging).

This especially stings because we had previously shipped guidance recommending VS Code users to use Run Without Debugging instead of the command line, advice that is now terrible. Our wish is to see 1.46-level performance restored.

[connor4312]

Thanks for the info. I tried to test this with a (somewhat smaller) TS project which took about 26 seconds to build both on the CLI and "run without debugging".

Two things:

1. Can you try setting outFiles: [] in your launch.json? I think we still do breakpoint prediction even in run without debugging which might be slowing things down if you have a very large workspace.
2. Can you share the launch.json you're using?

[RyanLamanskyInsite]

@connor4312 Thanks for the continued interest! Our project currently consists of ~1400 TypeScript source files totaling about 4.2 MB. I don't know how that compares to your test project, but we had to add some complexity (fork-ts-checker-webpack-plugin for better build parallelism) and make some sacrifices (IDE-only type checking in development builds) to get reasonable build times.

Regarding your suggestions:

1. outFiles: [] had no effect, unless I did it incorrectly (see below).
2. Here's the one I just tested:

   {
   "version": "0.2.0",
   "configurations": [
       {
           "type": "node",
           "request": "launch",
           "name": "Base",
           "program": "${workspaceFolder}/startDevelopment.js",
           "cwd": "${workspaceFolder}/",
           "outFiles": []
       }
   ]
   }

We may be able to share this code with Microsoft in the interest of fixing this issue.

[connor4312]

Ah, that's the trick. We didn't preserve the noDebug flag in child sessions, so while webpack wasn't in debug mode, the fork checker was. That will be fixed in the next nightly build.

[RyanLamanskyInsite]

@connor4312 I tested ms-vscode.js-debug-nightly v2020.7.3017 and saw a dramatic performance improvement, but still not close to matching the 1.46-era version:

Version	Time
1.46	39 seconds
1.47	336 seconds
1.47 js-debug v2020.7.3017	97 seconds

What else can be done to restore performance?

[worksofliam]

As a note, I am on 1.47.3 and I could only get debugging to work again with debug.javascript.usePreview: false.

Thanks

[connor4312]

@worksofliam please file an issue with further details and the template information here: https://github.com/microsoft/vscode-js-debug/issues/new/choose