Vscode: Revisit hardcoded timeout for resolving shell environment blocking first window open

[Ben-WD]

Issue Type: Bug

I'm developing a Node.js webserver application with the following launch configuration:

{
    // Use IntelliSense to learn about possible Node.js debug attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch Program",
            "type": "node",
            "program": "${workspaceFolder}/dist/server.js",
            "request": "launch",
            "preLaunchTask": "npm: build"
        },
        {
            "type": "node",
            "request": "attach",
            "name": "Attach by Process ID",
            "processId": "${command:PickProcess}",
            "protocol": "inspector"
        }
    ]
}

This has been working perfectly until version 1.49 has been installed. Since then, I get the following error when launching the application:

_Can't find Node.js binary "node": path does not exist. Make sure Node.js is installed and in your PATH, or set the "runtimeExecutable" in your launch.json_

Output from echo $PATH:

/Users/ben/.rbenv/shims:/Users/ben/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/ben/Library/Android/sdk/platform-tools/

Out from which node:

/usr/local/bin/node

Of course I can add the argument _runtimeExecutable_ to launch.json, but I think this should not be necessary.

VS Code version: Code 1.49.0 (e790b931385d72cf5669fcefc51cdf65990efa5d, 2020-09-10T17:39:53.251Z)
OS version: Darwin x64 19.6.0

System Info

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz (12 x 2600)|
|GPU Status|2d_canvas: enabled
flash_3d: enabled
flash_stage3d: enabled
flash_stage3d_baseline: enabled
gpu_compositing: enabled
metal: disabled_off
multiple_raster_threads: enabled_on
oop_rasterization: enabled
opengl: enabled_on
protected_video_decode: unavailable_off
rasterization: enabled
skia_renderer: disabled_off_ok
video_decode: enabled
webgl: enabled
webgl2: enabled|
|Load (avg)|2, 2, 2|
|Memory (System)|16.00GB (0.02GB free)|
|Process Argv||
|Screen Reader|no|
|VM|0%|

Extensions (13)

Extension|Author (truncated)|Version
---|---|---
angulardoc-vscode|Ang|6.1.3
vscode-eslint|dba|2.1.8
xml|Dot|2.5.1
EditorConfig|Edi|0.15.1
vscode-npm-script|eg2|0.3.13
prettier-vscode|esb|5.6.0
php-debug|fel|1.13.0
twig-language-2|mbl|0.9.2
debugger-for-chrome|msj|4.12.10
vscode-react-native|msj|0.17.0
vscode-jest|Ort|3.2.0
vscode-icons|vsc|10.2.0
markdown-all-in-one|yzh|3.3.0

[connor4312]

Where do you have your PATH configured in that way? If you launch VS Code from the shell (code -- with no existing running VS Code instance) it will inherit those variables, but if you launch it from the desktop app it might not have the same variables

You can see the PATH that VS Code has by running Developer: Toggle Developer Tools and entering process.env.PATH in the console.

[Ben-WD]

@connor4312 Output from Developer tools console:

process.env.PATH
"/Users/ben/.rbenv/shims:/Users/ben/bin:/usr/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Apple/usr/bin:/Users/ben/Library/Android/sdk/platform-tools/"

Since /usr/local/bin is in path, everything should be working. It has been working for month until 1.49 was installed automatically.

[qiulang]

I have the same problem after I upgraded to 1.49 !

Version: 1.49.0
Commit: e790b931385d72cf5669fcefc51cdf65990efa5d
Date: 2020-09-10T17:39:53.251Z
Electron: 9.2.1
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Darwin x64 19.6.0

I hit this error

If I changed runtimeExecutable I hit the following error

If I changed runtimeExecutable and runtimeArgs I hit the following error

[connor4312]

That's coming from your shell.

In js-debug to find Node we run which node or where node in the current environment. https://github.com/microsoft/vscode-js-debug/blob/8581c0bcda559b775d8666fb5765641c4118498b/src/common/pathUtils.ts#L15 Your observation that running npm directly does not find Node validates that the environment is wrong in the ext host.

As a workaround, you may be able to get things to work by setting console: integratedTerminal in your launch config along with the runtime executable, so that your program is run in a real shell.

@sandy081 / @isidorn did something change in 1.49 that would interfere with the environment that the extension host receives?

[qiulang]

Hi added console: integratedTerminal fixed the problem, but even more strange is that after I restarted vscode the problem goes away!

I didn't remember whether I restarted vscode yesterday but today that did fix the problem!

[liheeng]

I had same problem after upgrading to 1.49.0.

[adambiggs]

Same problem after upgrading to 1.49.0. Problem went away after downgrading to 1.48.2.

[sandy081]

Sorry, I have no idea. If it is extensionHost related pinging @alexdima

[alexdima]

Can someone impacted please try:

• open developer tools (Help > Toggle Developer Tools)
• in the console, evaluate process.env['PATH']. Is this the same $PATH as in your terminal?
• also evaluate process.env['DYLD_LIBRARY_PATH']

The only change that happened in this timeframe around the extension host process launching that I'm aware of is https://github.com/microsoft/vscode/commit/1b5fbcabd86f522da49c59fd80a90745f8a86f10 which removes DYLD_LIBRARY_PATH from the environment because it was causing some crashes, but that should not impact the PATH env variable.

ping @joaomoreno

[sweettyler]

I got an error message right after launching vscode: We did not find "node" on your path, so can not enable auto-attach in your environment ... on Linux.

I am using the insider version and do an update everyday. I don't have this issue yesterday, so the problem must be caused by changes between the insider version "d1f267742169584db010716d92addf50d4cd8139" and "9e505675670d65138405321a60b0df4ddec28799".

Ref: https://github.com/microsoft/vscode/issues/106938, which was marked(?!) as a "duplicate" of this one.

[sweettyler]

And in my case, installing the nightly version of JavaScript Debugger can make that error message gone (https://github.com/microsoft/vscode/issues/106938).

Any explanation?

[connor4312]

I'm not sure how the debugger version is related to the issue, I haven't touched this area since the stable release. Curious whether using the nightly works for everyone, like @Ben-WD and @qiulang.

[vsellen]

Just updated and have what is likely a related problem. In my case I have the path to electron specified in launch.json:

{ "type": "node", "request": "launch", "name": "Electron Player2", "runtimeExecutable": "~/workspace/electron_build/electron_x/dist/electron", "program": "${workspaceFolder}/app/main.js", "console":"integratedTerminal", "args": ["--playernum=player2"] },
Error message on launching debug states that the path does not exist:

This worked correctly before updating to 1.49.0. Hope this is useful.

Version: 1.49.0
Commit: e790b931385d72cf5669fcefc51cdf65990efa5d
Date: 2020-09-10T13:20:50.359Z
Electron: 9.2.1
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Linux x64 4.15.0-112-generic

[connor4312]

That's not related, but does it work if you replace the tilde ~ with the complete path? We don't untildify those at the moment, and I know 'some things' fail with them.

[vsellen]

Thanks. Untildifying did make a difference. Now I am getting a permission denied error in the debug console and no popup dialog. I will try to track that down, but as you said this is not related to the issue above.

[qiulang]

@connor4312 After I restart vscode I don't have the problem any more. I tried to reproduce it but I can't

[greglnye]

Same problem here when platform is WSL but works fine when platform is Windows.

Version: 1.49.1 (user setup)
Commit: 58bb7b2331731bf72587010e943852e13e6fd3cf
Date: 2020-09-16T23:27:51.792Z
Electron: 9.2.1
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Windows_NT x64 10.0.20170

Opened VS Code from WSL terminal ( code . ) and Launch Program

Received error message: _Can't find Node.js binary "node": path does not exist. Make sure Node.js is installed and in your PATH, or set the "runtimeExecutable" in your launch.json_

Output from: echo "$PATH" (in WSL: Ubuntu-20.04 terminal)
/home/greg/.asdf/shims:/home/greg/.asdf/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/c/Python38/Scripts/:/c/Python38/:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/WINDOWS/System32/WindowsPowerShell/v1.0/:/c/WINDOWS/System32/OpenSSH/:/c/Program Files/PowerShell/7/:/c/Program Files/dotnet/:/c/Program Files/Git/cmd:/c/Program Files/Docker/Docker/resources/bin:/c/ProgramData/DockerDesktop/version-bin:/c/Program Files/nodejs/:/c/ProgramData/chocolatey/bin:/c/Users/Greg/AppData/Local/Microsoft/WindowsApps:/c/Users/Greg/AppData/Local/Programs/Microsoft VS Code Insiders/bin:/c/Users/Greg/AppData/Roaming/npm:/c/Users/Greg/AppData/Local/Programs/Microsoft VS Code/bin:/snap/bin:/home/greg/.local/bin:/usr/local/go/bin:/home/greg/go/bin:/home/greg/dart-sass:/home/greg/.fzf/bin:/home/greg/.local/bin:/usr/local/go/bin:/home/greg/go/bin:/home/greg/dart-sass

Output from: which node (in WSL: Ubuntu-20.04 terminal)
/home/greg/.asdf/shims/node

Output from: process.env['PATH'] (in VS Code dev console)
C:\Python38\Scripts\;C:\Python38\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\PowerShell\7\;C:\Program Files\dotnet\;C:\Program Files\Git\cmd;C:\Program Files\Docker\Docker\resources\bin;C:\ProgramData\DockerDesktop\version-bin;C:\Program Files\nodejs\;C:\ProgramData\chocolatey\bin;C:\Users\GregAppData\Local\Microsoft\WindowsApps;C:\Users\GregAppData\Local\Programs\Microsoft VS Code Insiders\bin;C:\Users\GregAppData\Roaming\npm;C:\Users\GregAppData\Local\Programs\Microsoft VS Code\bin

No WSL paths!

Works with work-around by adding:

"linux": {
        "runtimeExecutable": "/home/greg/.asdf/shims/node"
}

to launch.json

launch.json:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "type": "node",
            "request": "launch",
            "name": "Launch Program",
            "skipFiles": [
                "<node_internals>/**"
            ],
            "program": "${workspaceFolder}/app.js",
            "linux": {
                "runtimeExecutable": "/home/greg/.asdf/shims/node"
            }
        }
    ]
}

Also just to check, switched to Windows with Remote-WSL: Reopen Folder in Windows and Launch Program

No errors, works fine.

All above is reproducible.

[connor4312]

@greglnye do you add the .asdf shims to your path inside your .bashrc or similar file? If so, VS Code will _only_ pick those up if you also launched the VS Code application from the shell--which is not possible in remote scenarios. You may be able to fix this by setting the shims path in your .profile instead. (my previous investigation into this: https://github.com/microsoft/vscode-js-debug/issues/717)

[alexdima]

cc @aeschli who has recently looked into some environmental variable fixes for WSL.

[MatayoshiMariano]

Did same thing as @greglnye and @connor4312 said, set up runtimeExecutable to whatever path your node executable is.
Since i'm using nvm and on a macbook

"runtimeExecutable": "/Users/USERNAME/.nvm/versions/node/v8.10.0/bin/node"

[connor4312]

@MatayoshiMariano nvm is a known case where (in their default install) we won't always pick it up, because it's set in your .bashrc which isn't run by VS Code and won't be applied unless you launch code from the command line. See here https://github.com/microsoft/vscode-js-debug/issues/717#issuecomment-680190832

[gabgagnon]

I had the same problem. Many of you restarted VScode so i tried it and it solved the problem. Thanks you guys.

[PRossetti]

Hi! I'm having the same problem. I had this problem in some projects and after updating to Visual Studio Code 1.49.3 it's happening to me in all the projects so I cannot debug any of my applications. Please help! I don't know what else to try, I have already restarted the software several times, restarted the Mac and installing another versión of node with nvm but the problem keeps appearing.
Hope you can help me,
best regards!

[connor4312]

@PRossetti where is Node installed?

[MatayoshiMariano]

@MatayoshiMariano nvm is a known case where (in their default install) we won't always pick it up, because it's set in your .bashrc which isn't run by VS Code and won't be applied unless you launch code from the command line. See here microsoft/vscode-js-debug#717 (comment)

Before upgrading 1.49 everything was working fine

[Ben-WD]

@MatayoshiMariano nvm is a known case where (in their default install) we won't always pick it up, because it's set in your .bashrc which isn't run by VS Code and won't be applied unless you launch code from the command line. See here microsoft/vscode-js-debug#717 (comment)

Before upgrading 1.49 everything was working fine

I'm using also nvm and never head a problem before updating to 1.49. Problem was gone for days and appeared suddenly again some days ago. Restarting VSCode fixed it.

[indieocean]

Had the problem using vscode 1.49.3 and NVM on a project that had .vscode configuration without runtimeVersion set.

I set "runtimeVersion": "12.16.3" which is the active NVM version and it worked.

[connor4312]

From what I've seen so far in this issue, the issue seems to be due to setting or updating paths in .*rc files. To summarize what I mentioned above--on most operating systems these variables are not automatically set for desktop applications. If you launch VS Code from the shell, though (without any other VS Code window open), they _will_ be inherited. Since it's dependent on how its launched and how your system is set up, restarting VS Code might fix it.

Alternately, you can set the path to your runtimeExecutable or, if you're using a a supported version manager like nvm or nvs, set runtimeVersion so that js-debug will do the lookup for you.

There are an assortment of ways, again depending on your OS, to set environment variables in a way that they're inherited in applications by default. For example:

• Ubuntu (for a shortcut) https://help.ubuntu.com/community/EnvironmentVariables#Launching_desktop_application_with_an_environment_variable
• Ubuntu (user-wide or system-wide environment variables) https://help.ubuntu.com/community/EnvironmentVariables#Persistent_environment_variables
• OSX via the /etc/launchd.conf file

[alexrecuenco]

I am not sure why you have closed this again.

There seems to be a difference in behavior between 1.48 and 1.49 that is causing all these issues, I am not sure if this change could at least be explained or documented in some way.

I've gotten the same issue myself on OSX.

I reverted back to 1.48 and the issue stopped.

[connor4312]

@alexrecuenco how do you have node installed, where is which node?

[alexrecuenco]

@connor4312 Node is installed on /Users/macintoshhd/.nvm/versions/node/v13.14.0/bin/node (I am using nvm)

[alexrecuenco]

Keep in mind that it is working on 1.48 with no changes to my setup, so something has happened between 1.48 and 1.49 that changed how environment variables are inherited on the debug creation.

I must say, in my case, It is really inconvenient if this change is purposeful. We use vscode because with the correct setup for new developers "it just works". But if we need to change environment variables on /etc/launchd.conf it would be inconvenient.

Thanks for the effort looking into this.

[connor4312]

cc @deepak1556 -- I'm unable to reproduce the issue described here, anything in Electron you know of?

[alexrecuenco]

I forgot to mention it, but my PATH environment in process.env['PATH'] in 1.49 is simply /bin:/sbin/.. just the basic default ones.

On the other hand, when I went back to 1.48 my process.env['PATH'] included my profile PATH environment

[alexdima]

@joaomoreno @bpasero Did we change anything in the way we read shell env variables between 1.48 and 1.49 ?

[bpasero]

@alexdima yes, for sandbox work: https://github.com/microsoft/vscode/commit/653e7e26df3be4cc5185982a8a4780b44523ef8e

But conceptually it should still work as before, though I decreased the timeout from 10s to 3s. To verify that is the issue, the devtools would show a warning message such as: Preload: Unable to resolve shell environment in a reasonable time

@alexrecuenco can you check that?

[amandapouget]

Same problem and restarting VSCode does not fix it.

[alexrecuenco]

Good afternoon,

I was unable to reproduce this error on version 1.49 again, it is true that my computer was particularly slow when this showed up (running some docker images).

However, after your comments @bpasero, I added a sleep 5 command on my bash profile and that made me able to reproduce the same issue, inconsistently I may add.

preload.js:177 Preload: Unable to resolve shell environment in a reasonable time.

After running a >Developer: Reload Window command, sometimes the node executable becomes available again

This is the copy-pasted devtools console log when it failed.

Just to be clear, AFTER seeing this console log, (seeing the process.env['PATH'] set correctly) executing the debug tools still doesn't work, it only works after a window reload.

preload.js:177 Preload: Unable to resolve shell environment in a reasonable time
(anonymous) @ /Applications/Visual Studio Code 1.49.app/Contents/Resources/app/out/vs/base/parts/sandbox/electron-browser/preload.js:5
TMScopeRegistry.ts:45 Overwriting grammar scope name to file mapping for scope source.r.
Old grammar file: file:///Applications/Visual%20Studio%20Code%201.49.app/Contents/Resources/app/extensions/r/syntaxes/r.tmLanguage.json.
New grammar file: file:///Users/macintoshhd/.vscode/extensions/ikuyadeu.r-1.4.6/syntax/r.json
register @ TMScopeRegistry.ts:43
TMScopeRegistry.ts:45 Overwriting grammar scope name to file mapping for scope source.yaml.
Old grammar file: file:///Applications/Visual%20Studio%20Code%201.49.app/Contents/Resources/app/extensions/yaml/syntaxes/yaml.tmLanguage.json.
New grammar file: file:///Users/macintoshhd/.vscode/extensions/redhat.vscode-yaml-0.11.1/syntaxes/yaml.tmLanguage.json
register @ TMScopeRegistry.ts:43
console.ts:137 [Extension Host] Sync : Connected with user : 'alex-ubitec'
console.ts:137 [Extension Host] rejected promise not handled within 1 second: Git error {  "exitCode": 128,  "gitErrorCode": "IsInSubmodule",  "stdout": "",  "stderr": "fatal: Pathspec '/Users/macintoshhd/ubibot-workspace/ubibot-botkit/src' is in submodule 'ubibot-botkit'\n"}
t.log @ console.ts:70
log.ts:197   ERR Git error
3console.ts:137 [Extension Host] rejected promise not handled within 1 second: Git error {  "exitCode": 128,  "gitErrorCode": "IsInSubmodule",  "stdout": "",  "stderr": "fatal: Pathspec '/Users/macintoshhd/ubibot-workspace/ubibot-botkit/src' is in submodule 'ubibot-botkit'\n"}
t.log @ console.ts:70
console.ts:137 [Extension Host] [vscode-icons] v11.0.0 activated!
console.ts:137 [Extension Host] rejected promise not handled within 1 second: Git error {  "exitCode": 128,  "gitErrorCode": "IsInSubmodule",  "stdout": "",  "stderr": "fatal: Pathspec '/Users/macintoshhd/ubibot-workspace/ubibot-botkit/src' is in submodule 'ubibot-botkit'\n"}
t.log @ console.ts:70
log.ts:197   ERR Git error
3console.ts:137 [Extension Host] rejected promise not handled within 1 second: Git error {  "exitCode": 128,  "gitErrorCode": "IsInSubmodule",  "stdout": "",  "stderr": "fatal: Pathspec '/Users/macintoshhd/ubibot-workspace/ubibot-botkit/src' is in submodule 'ubibot-botkit'\n"}
t.log @ console.ts:70
console.ts:137 [Extension Host] No editors associated with document: /Users/macintoshhd/ubibot-workspace/ubibot-botkit/tsconfig.json
t.log @ console.ts:70
log.ts:197   ERR No application in the Launch Services database matches the input criteria.: Error: No application in the Launch Services database matches the input criteria.
DevTools failed to load SourceMap: Could not load content for file:///Applications/Visual Studio Code 1.49.app/Contents/Resources/app/node_modules.asar/semver-umd/lib/semver-umd.js.map: 
DevTools failed to load SourceMap: Could not load content for file:///Applications/Visual Studio Code 1.49.app/Contents/Resources/app/node_modules.asar/xterm/lib/xterm.js.map: 
DevTools failed to load SourceMap: Could not load content for file:///Applications/Visual Studio Code 1.49.app/Contents/Resources/app/node_modules.asar/xterm-addon-unicode11/lib/xterm-addon-unicode11.js.map: 
DevTools failed to load SourceMap: Could not load content for file:///Applications/Visual Studio Code 1.49.app/Contents/Resources/app/node_modules.asar/xterm-addon-search/lib/xterm-addon-search.js.map: 
DevTools failed to load SourceMap: Could not load content for file:///Applications/Visual Studio Code 1.49.app/Contents/Resources/app/node_modules.asar/node-pty/lib/index.js.map: 
DevTools failed to load SourceMap: Could not load content for file:///Applications/Visual Studio Code 1.49.app/Contents/Resources/app/node_modules.asar/node-pty/lib/unixTerminal.js.map: 
DevTools failed to load SourceMap: Could not load content for file:///Applications/Visual Studio Code 1.49.app/Contents/Resources/app/node_modules.asar/node-pty/lib/terminal.js.map: 
DevTools failed to load SourceMap: Could not load content for file:///Applications/Visual Studio Code 1.49.app/Contents/Resources/app/node_modules.asar/node-pty/lib/eventEmitter2.js.map: 
DevTools failed to load SourceMap: Could not load content for file:///Applications/Visual Studio Code 1.49.app/Contents/Resources/app/node_modules.asar/node-pty/lib/utils.js.map: 
DevTools failed to load SourceMap: Could not load content for file:///Applications/Visual Studio Code 1.49.app/Contents/Resources/app/node_modules.asar/vscode-textmate/release/main.js.map: 
process.env['PATH']
"/usr/local/opt/[email protected]/bin:/Users/macintoshhd/.nvm/versions/node/v13.14.0/bin:/usr/local/clang7/bin:/Users/macintoshhd/.gem/bin:/usr/local/opt/ruby/bin:/Users/macintoshhd/.cargo/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/usr/local/aria2/bin:/usr/local/MacGPG2/bin:/opt/X11/bin:/Library/Apple/usr/bin:/Users/macintoshhd/.development/bin:/Users/macintoshhd/.local/bin:/Users/macintoshhd/Library/Python/3.7/bin"

This is the copy-pasted devtools console log after a reload succeded

DevTools failed to load SourceMap: Could not load content for file:///Applications/Visual Studio Code 1.49.app/Contents/Resources/app/node_modules.asar/semver-umd/lib/semver-umd.js.map: 
DevTools failed to load SourceMap: Could not load content for file:///Applications/Visual Studio Code 1.49.app/Contents/Resources/app/node_modules.asar/xterm/lib/xterm.js.map: 
DevTools failed to load SourceMap: Could not load content for file:///Applications/Visual Studio Code 1.49.app/Contents/Resources/app/node_modules.asar/xterm-addon-unicode11/lib/xterm-addon-unicode11.js.map: 
DevTools failed to load SourceMap: Could not load content for file:///Applications/Visual Studio Code 1.49.app/Contents/Resources/app/node_modules.asar/xterm-addon-search/lib/xterm-addon-search.js.map: 
DevTools failed to load SourceMap: Could not load content for file:///Applications/Visual Studio Code 1.49.app/Contents/Resources/app/node_modules.asar/node-pty/lib/index.js.map: 
DevTools failed to load SourceMap: Could not load content for file:///Applications/Visual Studio Code 1.49.app/Contents/Resources/app/node_modules.asar/node-pty/lib/unixTerminal.js.map: 
DevTools failed to load SourceMap: Could not load content for file:///Applications/Visual Studio Code 1.49.app/Contents/Resources/app/node_modules.asar/node-pty/lib/terminal.js.map: 
DevTools failed to load SourceMap: Could not load content for file:///Applications/Visual Studio Code 1.49.app/Contents/Resources/app/node_modules.asar/node-pty/lib/eventEmitter2.js.map: 
DevTools failed to load SourceMap: Could not load content for file:///Applications/Visual Studio Code 1.49.app/Contents/Resources/app/node_modules.asar/node-pty/lib/utils.js.map: 
DevTools failed to load SourceMap: Could not load content for file:///Applications/Visual Studio Code 1.49.app/Contents/Resources/app/node_modules.asar/vscode-textmate/release/main.js.map: 
TMScopeRegistry.ts:45 Overwriting grammar scope name to file mapping for scope source.r.
Old grammar file: file:///Applications/Visual%20Studio%20Code%201.49.app/Contents/Resources/app/extensions/r/syntaxes/r.tmLanguage.json.
New grammar file: file:///Users/macintoshhd/.vscode/extensions/ikuyadeu.r-1.4.6/syntax/r.json
register @ TMScopeRegistry.ts:43
s @ TMGrammarFactory.ts:54
_getOrCreateGrammarFactory @ abstractTextMateService.ts:181
async function (async)
_getOrCreateGrammarFactory @ abstractTextMateService.ts:181
(anonymous) @ abstractTextMateService.ts:247
_registerDefinitionIfAvailable @ abstractTextMateService.ts:286
(anonymous) @ abstractTextMateService.ts:117
_handle @ extensionsRegistry.ts:76
acceptUsers @ extensionsRegistry.ts:76
_handleExtensionPoint @ abstractExtensionService.ts:396
_doHandleExtensionPoints @ abstractExtensionService.ts:332
_startLocalExtensionHost @ extensionService.ts:588
_scanAndHandleExtensions @ extensionService.ts:549
async function (async)
_scanAndHandleExtensions @ extensionService.ts:504
_initialize @ abstractExtensionService.ts:111
(anonymous) @ extensionService.ts:79
requestIdleCallback (async)
t.runWhenIdle @ async.ts:678
(anonymous) @ extensionService.ts:79
Promise.then (async)
W @ extensionService.ts:79
_createInstance @ instantiationService.ts:73
_createServiceInstance @ instantiationService.ts:187
_createServiceInstanceWithOwner @ instantiationService.ts:187
_createAndCacheServiceInstance @ instantiationService.ts:124
_getOrCreateServiceInstance @ instantiationService.ts:124
get @ serviceCollection.ts:26
initLayout @ layout.ts:258
(anonymous) @ workbench.ts:62
invokeFunction @ serviceCollection.ts:26
startup @ workbench.ts:62
open @ desktop.main.ts:108
async function (async)
open @ desktop.main.ts:69
t.main @ desktop.main.ts:295
(anonymous) @ workbench.js:167
async function (async)
(anonymous) @ workbench.js:167
(anonymous) @ bootstrap-window.js:93
t._invokeFactory @ loader.js:1135
t.complete @ loader.js:1135
s._onModuleComplete @ loader.js:1712
s._onModuleComplete @ loader.js:1712
s._resolve @ loader.js:1647
s.defineModule @ loader.js:1284
r @ loader.js:1712
c @ loader.js:795
(anonymous) @ workbench.common.main.ts:131
(anonymous) @ workbench.common.main.ts:131
t._createAndEvalScript @ loader.js:795
(anonymous) @ loader.js:795
u @ loader.js:904
(anonymous) @ loader.js:904
readFileAfterClose @ internal/fs/read_file_context.js:61
TMScopeRegistry.ts:45 Overwriting grammar scope name to file mapping for scope source.yaml.
Old grammar file: file:///Applications/Visual%20Studio%20Code%201.49.app/Contents/Resources/app/extensions/yaml/syntaxes/yaml.tmLanguage.json.
New grammar file: file:///Users/macintoshhd/.vscode/extensions/redhat.vscode-yaml-0.11.1/syntaxes/yaml.tmLanguage.json
register @ TMScopeRegistry.ts:43
s @ TMGrammarFactory.ts:54
_getOrCreateGrammarFactory @ abstractTextMateService.ts:181
async function (async)
_getOrCreateGrammarFactory @ abstractTextMateService.ts:181
(anonymous) @ abstractTextMateService.ts:247
_registerDefinitionIfAvailable @ abstractTextMateService.ts:286
(anonymous) @ abstractTextMateService.ts:117
_handle @ extensionsRegistry.ts:76
acceptUsers @ extensionsRegistry.ts:76
_handleExtensionPoint @ abstractExtensionService.ts:396
_doHandleExtensionPoints @ abstractExtensionService.ts:332
_startLocalExtensionHost @ extensionService.ts:588
_scanAndHandleExtensions @ extensionService.ts:549
async function (async)
_scanAndHandleExtensions @ extensionService.ts:504
_initialize @ abstractExtensionService.ts:111
(anonymous) @ extensionService.ts:79
requestIdleCallback (async)
t.runWhenIdle @ async.ts:678
(anonymous) @ extensionService.ts:79
Promise.then (async)
W @ extensionService.ts:79
_createInstance @ instantiationService.ts:73
_createServiceInstance @ instantiationService.ts:187
_createServiceInstanceWithOwner @ instantiationService.ts:187
_createAndCacheServiceInstance @ instantiationService.ts:124
_getOrCreateServiceInstance @ instantiationService.ts:124
get @ serviceCollection.ts:26
initLayout @ layout.ts:258
(anonymous) @ workbench.ts:62
invokeFunction @ serviceCollection.ts:26
startup @ workbench.ts:62
open @ desktop.main.ts:108
async function (async)
open @ desktop.main.ts:69
t.main @ desktop.main.ts:295
(anonymous) @ workbench.js:167
async function (async)
(anonymous) @ workbench.js:167
(anonymous) @ bootstrap-window.js:93
t._invokeFactory @ loader.js:1135
t.complete @ loader.js:1135
s._onModuleComplete @ loader.js:1712
s._onModuleComplete @ loader.js:1712
s._resolve @ loader.js:1647
s.defineModule @ loader.js:1284
r @ loader.js:1712
c @ loader.js:795
(anonymous) @ workbench.common.main.ts:131
(anonymous) @ workbench.common.main.ts:131
t._createAndEvalScript @ loader.js:795
(anonymous) @ loader.js:795
u @ loader.js:904
(anonymous) @ loader.js:904
readFileAfterClose @ internal/fs/read_file_context.js:61
console.ts:137 [Extension Host] No editors associated with document: /Users/macintoshhd/ubibot-workspace/ubibot-botkit/src/async-lock/async-lock.ts
t.log @ console.ts:70
$logExtensionHostMessage @ extHostTunnelService.ts:43
_doInvokeHandler @ rpcProtocol.ts:372
_invokeHandler @ rpcProtocol.ts:372
_receiveRequest @ rpcProtocol.ts:253
_receiveOneMessage @ rpcProtocol.ts:185
(anonymous) @ rpcProtocol.ts:51
fire @ event.ts:584
fire @ ipc.net.ts:459
_receiveMessage @ ipc.net.ts:792
(anonymous) @ ipc.net.ts:647
fire @ event.ts:584
acceptChunk @ ipc.net.ts:216
(anonymous) @ ipc.net.ts:137
t @ ipc.net.ts:859
emit @ events.js:223
addChunk @ _stream_readable.js:309
readableAddChunk @ _stream_readable.js:290
Readable.push @ _stream_readable.js:224
onStreamRead @ internal/stream_base_commons.js:181
console.ts:137 [Extension Host] Sync : Connected with user : 'alex-ubitec'
console.ts:137 [Extension Host] [vscode-icons] v11.0.0 activated!
console.ts:137 [Extension Host] No editors associated with document: /Users/macintoshhd/ubibot-workspace/ubibot-botkit/tsconfig.json
t.log @ console.ts:70
$logExtensionHostMessage @ extHostTunnelService.ts:43
_doInvokeHandler @ rpcProtocol.ts:372
_invokeHandler @ rpcProtocol.ts:372
_receiveRequest @ rpcProtocol.ts:253
_receiveOneMessage @ rpcProtocol.ts:185
(anonymous) @ rpcProtocol.ts:51
fire @ event.ts:584
fire @ ipc.net.ts:459
_receiveMessage @ ipc.net.ts:792
(anonymous) @ ipc.net.ts:647
fire @ event.ts:584
acceptChunk @ ipc.net.ts:216
(anonymous) @ ipc.net.ts:137
t @ ipc.net.ts:859
emit @ events.js:223
addChunk @ _stream_readable.js:309
readableAddChunk @ _stream_readable.js:290
Readable.push @ _stream_readable.js:224
onStreamRead @ internal/stream_base_commons.js:181

[gavinwyf]

set runtimeVersion to current version (node version nvm set).

[markcarroll]

Just a comment to those finding this issue. My vscode instance was loaded by MacOS on a reboot using the "reopen all windows" option. So I believe it was started before the path was set for node in my shell. After closing and restarting vscode again manually it seemed to work just fine. Not sure if this is the case for everyone, but maybe an idea to help debug.

[scottmercer]

vscode restart fixed this issue for me.

[connor4312]

@bpasero should I reassigned this to you? As far as I see there's no action I should take on the debugger side here.

[bpasero]

I can look into it if someone can post steps how to reliably reproduce this. Otherwise this issue will close in 7 days automatically.

[connor4312]

We have a substantial number of reports for this (~20 in this thread and some duplicates) that it's probably worth trying to diagnose even barring a reliable repro.

[bpasero]

Yeah sure, I am happy to run through steps that are minimal without a lot of setup on my end if possible.

[alexrecuenco]

I was able to reproduce this getting

1) Any node's project opened in viscose
2) Add the line sleep 10 to your profile or bashrc
3) Quit vscode, then open it again on that project. Most times when you try to run the debugger it will show the message above
4) Run the reload windows command, you'll notice that now you can run the nodejs debugger.

Let me know if you need me to create some minimal project... I just don't think I have the time to do it right now

[bpasero]

@alexrecuenco that is expected, we only wait 3s before giving up on resolving the shell environment:

https://github.com/microsoft/vscode/blob/99b13b8fbfea262f03d4ec818c857003b463c7b2/src/vs/base/parts/sandbox/electron-browser/preload.js#L229-L234

This used to be 10s and now is 3s, so there was a change. But I really see no reason why resolving the shell environment would take any longer than <1s. Note that this blocks the window from opening, so it is really bad for performance.

The fact that it works after a reload is because then we have an already resolved shell environment that we can pick without waiting.

[alexrecuenco]

@bpasero If you don't plan to change it back, would it be possible to write some documentation about the change? And, if possible, some setting to set back the previous default.

Sometimes some bash extension can take a while to load, specially when the computer is strained (running a debugger, a docker container, and a db at the same time). And this seems to have caused many people here to get a very counterintuitive result that is very hard to debug without knowing this quirk of the system.

Thanks for looking into this.

[bpasero]

fyi @joaomoreno on my change. I really think this is not the right solution all in all because for a user you may be surprised that opening the first window always takes up to 10s (now 3s) without fully understanding what is going on in the background.

I think a setting for this could work, but is hard to discover too. Alternatively we could simply proceed with opening the workbench and let the process environment come in async with possibly an event to emit once that happens so that parties that need to update can subscribe to?

[vscode-triage-bot]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[joaomoreno]

But I really see no reason why resolving the shell environment would take any longer than <1s.

It happens a lot, and that's why it was set to 10.

Note that this blocks the window from opening, so it is really bad for performance

@jrieken made sure this doesn't block the window from opening, just the workbench from loading, back when he introduced lazyEnv. @bpasero, this is now known as whenEnvResolved, since your latest refactorings.

Overall, the user env is really only needed when further spawning more processes, so the real fix here is to just have an IExecutionService which should get the user env whenever spawning processes, instead of having that dependency in the renderer. This is a big refactoring which will likely break many things, but it's the right thing to do. I've created this item to follow up: https://github.com/microsoft/vscode/issues/108804. Note that while the workbench will load more things, a lot of other things can't really work until the user env is loaded or timed out: terminals, tasks, extension host. Probably more, since we have configuration setting values which depend on environment values.... So that's fun.

Until then, I suggest to revert to the 10s timeout. Adding a setting for it is not good. Because every single user timing out will always file an issue before they even consider searching for a setting.

[bpasero]

@jrieken made sure this doesn't block the window from opening, just the workbench from loading, back when he introduced
lazyEnv. @bpasero, this is now known as whenEnvResolved, since your latest refactorings.

I really do not see how this good. The workbench not loading in 10s is equally bad as the window not loading in 10s. All that matters is the time to blinking cursor in the editor and that is what we measure in our perf runs.

https://github.com/microsoft/vscode/issues/108804 sounds like a good idea and I think we should really tackle it soon not late.

Back to 3s vs 10s: what I don't like is this:

• even 10s might not be enough it is just a number you or Jo picked which may fail or may not fail
• if this happens (you wait 10s) there is no feedback as to why you waited for 10s
• users will never learn that they have to look into their shell config to figure out why VSCode is slow starting up

If we had a setting this would at least enable this flow:

• workbench starts slow
• we can show a notification offering to inform user why it was slow
• we can even notify that we could not resolve the shell environment in time
• we can guide users towards tweaking the setting to either reduce the time or increase it as needed

[alexrecuenco]

Sorry for interjecting,

I understand your concern @bpasero, but in my opinion ---from a user perspective--- it'd be better not to modify the current behavior. Thus avoiding a couple threads of confused people from undocumented behavior changed.

[milessa42]

I've had this same error happen recently as well, rendering VSCode useless for me until I figured out what was going on, and it took me a good bit of time to even figure out that this was the root cause, as I didn't get notified that the environment loading was timed out.

My eventual "resolution" was to disable extensions until my environment could be loaded in time. Given that I actually would like to use some of these extensions I disabled, I obviously can't consider this a real fix (this is something I will have to shelve VSCode for if it a must-have extension that is causing the problem, but I haven't gotten that far yet).

A setting to override the timeout would be great, I could change it and move on. The initial timeout is probably fine for a lot of people and the arguments for not having it set to 10s as a default are solid, but the lack of feedback about the environment not loading combined with the inability to override this behavior is a killer combination. I see that there is a feature request already put in to provide a real fix, but it would be amazing if, in the interim, we can get a setting + a prompt to update this setting if the environment load runs afoul of that timeout.

[sultanmyrza]

Developer: Reload Windows resolved my issue. Might not work for you just try. It worked for me.

[e-tip]

I have this issue too with 1.50. never had with 1.49 ( or at least it never happened ). Solved with Developer: Reload windows

[klemensz]

I've had the same problem with version 1.51.1 on macOS and solved (or worked around) it by re-starting VSCode.

[paullewisn]

Same problem Developer: Reload windows solved it