Extension host terminated unexpectedly on VSCode 1.26.0

[hbergren]

Your environment

• vscode-ruby version: 0.20.0
• Ruby version: (using VS Code multi-root workspace)
  • 2 directories using ruby 2.4.3p205 (2017-12-14 revision 61247) [x86_64-darwin17]
  • 1 directory using ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-darwin17]
• Ruby version manager (if any): rbenv 1.1.1
• VS Code version: 1.26.0
• Operating System: Mac OS X 10.13.5 (17F77)
• Using language server? No

Expected behavior

Things just keep working as expected.

Actual behavior

After upgrading VS Code to 1.26.0, I receive an Extension host terminated unexpectedly. error message after opening a Ruby file in VS Code.

It appears to start running the Indexing ruby source files..., as I see that in the toolbar right before it crashes.

I already tried disabling the Solargraph extension in case this extension was colliding with the Solargraph extension somehow, but that still resulted in the same error message.

Extension Service log:

[2018-08-13 17:15:35.651] [exthost1] [info] extension host started
[2018-08-13 17:15:35.670] [exthost1] [info] ExtensionService#_doActivateExtension vscode.debug-auto-launch {"startup":true,"activationEvent":"*"}
[2018-08-13 17:15:35.670] [exthost1] [info] ExtensionService#loadCommonJSModule /Applications/Visual Studio Code.app/Contents/Resources/app/extensions/debug-auto-launch/out/extension
[2018-08-13 17:15:35.680] [exthost1] [info] ExtensionService#_doActivateExtension vscode.emmet {"startup":true,"activationEvent":"*"}
[2018-08-13 17:15:35.680] [exthost1] [info] ExtensionService#loadCommonJSModule /Applications/Visual Studio Code.app/Contents/Resources/app/extensions/emmet/out/extension
[2018-08-13 17:15:35.747] [exthost1] [info] ExtensionService#_doActivateExtension vscode.git {"startup":true,"activationEvent":"*"}
[2018-08-13 17:15:35.747] [exthost1] [info] ExtensionService#loadCommonJSModule /Applications/Visual Studio Code.app/Contents/Resources/app/extensions/git/out/main
[2018-08-13 17:15:35.933] [exthost1] [info] ExtensionService#_doActivateExtension vscode.merge-conflict {"startup":true,"activationEvent":"*"}
[2018-08-13 17:15:35.933] [exthost1] [info] ExtensionService#loadCommonJSModule /Applications/Visual Studio Code.app/Contents/Resources/app/extensions/merge-conflict/out/extension
[2018-08-13 17:15:35.950] [exthost1] [info] ExtensionService#_doActivateExtension vscode.search-rg {"startup":true,"activationEvent":"*"}
[2018-08-13 17:15:35.950] [exthost1] [info] ExtensionService#loadCommonJSModule /Applications/Visual Studio Code.app/Contents/Resources/app/extensions/search-rg/out/extension
[2018-08-13 17:15:35.958] [exthost1] [info] ExtensionService#_doActivateExtension christian-kohler.path-intellisense {"startup":true,"activationEvent":"*"}
[2018-08-13 17:15:35.958] [exthost1] [info] ExtensionService#loadCommonJSModule /Users/hbergren/.vscode/extensions/christian-kohler.path-intellisense-1.4.2/out/src/extension
[2018-08-13 17:15:35.971] [exthost1] [info] ExtensionService#_doActivateExtension dbaeumer.vscode-eslint {"startup":true,"activationEvent":"*"}
[2018-08-13 17:15:35.971] [exthost1] [info] ExtensionService#loadCommonJSModule /Users/hbergren/.vscode/extensions/dbaeumer.vscode-eslint-1.4.12/client/out/extension
[2018-08-13 17:15:36.131] [exthost1] [info] ExtensionService#_doActivateExtension eamodio.gitlens {"startup":true,"activationEvent":"*"}
[2018-08-13 17:15:36.131] [exthost1] [info] ExtensionService#loadCommonJSModule /Users/hbergren/.vscode/extensions/eamodio.gitlens-8.5.4/out/extension
[2018-08-13 17:15:36.501] [exthost1] [info] ExtensionService#_doActivateExtension HookyQR.beautify {"startup":true,"activationEvent":"*"}
[2018-08-13 17:15:36.501] [exthost1] [info] ExtensionService#loadCommonJSModule /Users/hbergren/.vscode/extensions/hookyqr.beautify-1.3.2/extension
[2018-08-13 17:15:36.549] [exthost1] [info] ExtensionService#_doActivateExtension ms-vsliveshare.vsliveshare {"startup":true,"activationEvent":"*"}
[2018-08-13 17:15:36.549] [exthost1] [info] ExtensionService#loadCommonJSModule /Users/hbergren/.vscode/extensions/ms-vsliveshare.vsliveshare-0.3.514/out/src/extension
[2018-08-13 17:15:37.194] [exthost1] [info] ExtensionService#_doActivateExtension streetsidesoftware.code-spell-checker {"startup":true,"activationEvent":"*"}
[2018-08-13 17:15:37.194] [exthost1] [info] ExtensionService#loadCommonJSModule /Users/hbergren/.vscode/extensions/streetsidesoftware.code-spell-checker-1.6.10/out/src/extension
[2018-08-13 17:15:37.328] [exthost1] [info] ExtensionService#_doActivateExtension wayou.vscode-todo-highlight {"startup":true,"activationEvent":"*"}
[2018-08-13 17:15:37.328] [exthost1] [info] ExtensionService#loadCommonJSModule /Users/hbergren/.vscode/extensions/wayou.vscode-todo-highlight-1.0.4/src/extension
[2018-08-13 17:15:37.366] [exthost1] [info] ExtensionService#_doActivateExtension vscode.markdown-language-features {"startup":true,"activationEvent":"workspaceContains:README.md"}
[2018-08-13 17:15:37.366] [exthost1] [info] ExtensionService#loadCommonJSModule /Applications/Visual Studio Code.app/Contents/Resources/app/extensions/markdown-language-features/out/extension
[2018-08-13 17:15:37.470] [exthost1] [info] ExtensionService#_doActivateExtension castwide.solargraph {"startup":false,"activationEvent":"onLanguage:ruby"}
[2018-08-13 17:15:37.470] [exthost1] [info] ExtensionService#loadCommonJSModule /Users/hbergren/.vscode/extensions/castwide.solargraph-0.17.6/out/src/extension
[2018-08-13 17:15:37.844] [exthost1] [info] ExtensionService#_doActivateExtension rebornix.ruby {"startup":false,"activationEvent":"onLanguage:ruby"}

[codingdracula]

I am also getting this error after the update [Version 1.26.0]. I think there is some conflict with the newest update. Even with only the ruby extension installed this error happens.

edit: Attached an image of the developer console

[codingdracula]

I am also getting this error after the update [Version 1.26.0]. I think there is some conflict with the newest update. Even with only the ruby extension installed this error happens.

edit: Attached an image of the developer console

[hbergren]

Update: I can also reproduce the error in a normal non-multi-root VS Code workspace, with just a single directory.

[hbergren]

Update: I can also reproduce the error in a normal non-multi-root VS Code workspace, with just a single directory.

[wingrunr21]

Ok. I have not upgraded to 1.26.0 yet. I'll try and get to this tonight or tomorrow AM.

[wingrunr21]

Ok. I have not upgraded to 1.26.0 yet. I'll try and get to this tonight or tomorrow AM.

[darren987469]

I have the same problem when upgrading to 1.26.0

[darren987469]

I have the same problem when upgrading to 1.26.0

[wingrunr21]

Ok, so far I've traced this to be occurring in the legacy linter code. If you completely disable linting in the extension settings it appears to keep the extension host from crashing. I'm going to keep digging but that at least should allow you to edit Ruby files for the time being.

Edit:

This appears to be an Electron bug (electron/electron#13254 and electron/electron#13679). It was not present in Electron v1.7.x (eg VSCode <= 1.25.0) but is present in Electron v1.8.x and higher (and VSCode 1.26.0 is on Electron 2.0.5). Looking into mitigation on it.

[wingrunr21]

Ok, so far I've traced this to be occurring in the legacy linter code. If you completely disable linting in the extension settings it appears to keep the extension host from crashing. I'm going to keep digging but that at least should allow you to edit Ruby files for the time being.

Edit:

This appears to be an Electron bug (electron/electron#13254 and electron/electron#13679). It was not present in Electron v1.7.x (eg VSCode <= 1.25.0) but is present in Electron v1.8.x and higher (and VSCode 1.26.0 is on Electron 2.0.5). Looking into mitigation on it.

[TonyCTHsu]

Yeah, experiencing the same problem after upgrade to 1.26.

[TonyCTHsu]

Yeah, experiencing the same problem after upgrade to 1.26.

[hbergren]

Ok, so far I've traced this to be occurring in the legacy linter code. If you completely disable linting in the extension settings it appears to keep the extension host from crashing. I'm going to keep digging but that at least should allow you to edit Ruby files for the time being.

Thanks for the quick response and workaround!

[hbergren]

Ok, so far I've traced this to be occurring in the legacy linter code. If you completely disable linting in the extension settings it appears to keep the extension host from crashing. I'm going to keep digging but that at least should allow you to edit Ruby files for the time being.

Thanks for the quick response and workaround!

[wingrunr21]

TL;DR: Open VSCode via the code command line so it inherits your shell environment correctly OR set the paths to bundler/your linters to absolute paths.

This seems to be a combination of the previously mentioned Electron bug + the underlying problems this extension has with correctly detecting Ruby environments. The Electron bug gets triggered when the command that is passed to spawn can't be found in the VSCode environment. I solved this locally by both loading VSCode from my workspace directory (so that the proper shell variables are loaded) and by setting user/workspace settings to absolute paths for bundler/linters. This is a temp workaround for folks while I work to correctly detect the Ruby environment (which is work I was doing anyway for the language server).

@hbergren I don't have a good solution for your multi-root workspace right now. I'm very sorry. Multi-root workspace support is literally next on my list of support for the language server and I haven't gotten it done yet. For the time being the best I can say is you'll need to open a different editor instance for each root. I realize that sucks.

[wingrunr21]

TL;DR: Open VSCode via the code command line so it inherits your shell environment correctly OR set the paths to bundler/your linters to absolute paths.

This seems to be a combination of the previously mentioned Electron bug + the underlying problems this extension has with correctly detecting Ruby environments. The Electron bug gets triggered when the command that is passed to spawn can't be found in the VSCode environment. I solved this locally by both loading VSCode from my workspace directory (so that the proper shell variables are loaded) and by setting user/workspace settings to absolute paths for bundler/linters. This is a temp workaround for folks while I work to correctly detect the Ruby environment (which is work I was doing anyway for the language server).

@hbergren I don't have a good solution for your multi-root workspace right now. I'm very sorry. Multi-root workspace support is literally next on my list of support for the language server and I haven't gotten it done yet. For the time being the best I can say is you'll need to open a different editor instance for each root. I realize that sucks.

[wingrunr21]

I have to head to work but will continue to work on this tonight. I hope the workarounds I posted can get people through the day. If anyone else wants to take a look today here's where I am:

The specific Electron bug is triggered here. When the command is not found the file descriptor is invalid and attempting to end the stream causes the SIGPIPE. The problem is that particular attribute is still a Socket on the ChildProcess instance. We may be able to look at some attributes there to check if it is a valid Socket. I hadn't gotten there yet this morning.

[wingrunr21]

I have to head to work but will continue to work on this tonight. I hope the workarounds I posted can get people through the day. If anyone else wants to take a look today here's where I am:

The specific Electron bug is triggered here. When the command is not found the file descriptor is invalid and attempting to end the stream causes the SIGPIPE. The problem is that particular attribute is still a Socket on the ChildProcess instance. We may be able to look at some attributes there to check if it is a valid Socket. I hadn't gotten there yet this morning.

[codingdracula]

The bug seems to be a problem specifically with 1.26.0

For anyone looking for a work around so they can keep working, the previous version of vscode is available here: https://code.visualstudio.com/updates/v1_25

Don't forget to add, "update.channel": "none", to your user settings file.

Settings Sync package is super helpful in this case: https://marketplace.visualstudio.com/items?itemName=Shan.code-settings-sync

@wingrunr21 also gave some work around solutions if you want to stick with 1.26.0. For me, it seemed easier to downgrade for the time being since I didn't have any major issues with 1.25

[codingdracula]

The bug seems to be a problem specifically with 1.26.0

For anyone looking for a work around so they can keep working, the previous version of vscode is available here: https://code.visualstudio.com/updates/v1_25

Don't forget to add, "update.channel": "none", to your user settings file.

Settings Sync package is super helpful in this case: https://marketplace.visualstudio.com/items?itemName=Shan.code-settings-sync

@wingrunr21 also gave some work around solutions if you want to stick with 1.26.0. For me, it seemed easier to downgrade for the time being since I didn't have any major issues with 1.25

[wingrunr21]

@codingdracula You can continue to use the extension in 1.26.0. I posted several different workarounds for that while I work to properly mitigate it.

[wingrunr21]

@codingdracula You can continue to use the extension in 1.26.0. I posted several different workarounds for that while I work to properly mitigate it.

[gerrywastaken]

@wingrunr21 The work around of running code . didn't work for me and that's what I've always used anyway. I agree with @codingdracula that it's probably easier to just downgrade.

[gerrywastaken]

@wingrunr21 The work around of running code . didn't work for me and that's what I've always used anyway. I agree with @codingdracula that it's probably easier to just downgrade.

[wingrunr21]

@gerrywastaken it depends on your configuration settings. It all hinges in whether the VSCode spawn command can successfully execute the linter.

[wingrunr21]

@gerrywastaken it depends on your configuration settings. It all hinges in whether the VSCode spawn command can successfully execute the linter.

[gerrywastaken]

@wingrunr21 Yeah but without debug info I can't figure out which linter it's breaking on or why without a lot of trial and error.

edit: ok so I did the trial and error approach of removing linters till I found out which ones broke things.

[gerrywastaken]

@wingrunr21 Yeah but without debug info I can't figure out which linter it's breaking on or why without a lot of trial and error.

edit: ok so I did the trial and error approach of removing linters till I found out which ones broke things.

[wingrunr21]

@gerrywastaken noted it could be better but you can also look at your linter config and the PATH within process.env of VSCode and determine whether or not the linters are going to be found in that PATH. Would you mind posting your config (both linter and bundler) + if the linters are vendored in your bundle or globally installed?

The recommended fix for this upstream is to verify that the linter command being executed is an absolute path. I'm considering either that or doing a command -v check prior to linter execution on POSIX systems and bailing if that fails. Does anyone have a preference? The former solution means linters won't work unless they are configured to be absolute paths.

[wingrunr21]

@gerrywastaken noted it could be better but you can also look at your linter config and the PATH within process.env of VSCode and determine whether or not the linters are going to be found in that PATH. Would you mind posting your config (both linter and bundler) + if the linters are vendored in your bundle or globally installed?

The recommended fix for this upstream is to verify that the linter command being executed is an absolute path. I'm considering either that or doing a command -v check prior to linter execution on POSIX systems and bailing if that fails. Does anyone have a preference? The former solution means linters won't work unless they are configured to be absolute paths.

[darren987469]

@wingrunr21 If I have different versions of rubocop for different projects, how can I set it in the absolute paths way?

[darren987469]

@wingrunr21 If I have different versions of rubocop for different projects, how can I set it in the absolute paths way?

[hbergren]

@darren987469 , you could use VS Code workspace-specific settings.

Those would get saved in .vscode/ of the root directory of each workspace, or the .code-workspace file if using a multi-root workspace.

[hbergren]

@darren987469 , you could use VS Code workspace-specific settings.

Those would get saved in .vscode/ of the root directory of each workspace, or the .code-workspace file if using a multi-root workspace.

[wingrunr21]

Yes that’s the solution until I get the multi root support in place.

Also this is a short term mitigation solution. I do intend to fix it properly but want to get a patch release out.

[wingrunr21]

Yes that’s the solution until I get the multi root support in place.

Also this is a short term mitigation solution. I do intend to fix it properly but want to get a patch release out.

[wingrunr21]

note that a discussion is going on over in the VSCode repo around this as several extensions are affected:

Microsoft/vscode#56387

[wingrunr21]

note that a discussion is going on over in the VSCode repo around this as several extensions are affected:

Microsoft/vscode#56387

[gerrywastaken]

Would you mind posting your config (both linter and bundler) + if the linters are vendored in your bundle or globally installed?

Basically I just had specified a linter that didn't exist on my system at all. Insead of doing command -v wouldn't which <linter> || where <linter> work better?

edit: NM... I understand now: https://stackoverflow.com/a/677212

[gerrywastaken]

Would you mind posting your config (both linter and bundler) + if the linters are vendored in your bundle or globally installed?

Basically I just had specified a linter that didn't exist on my system at all. Insead of doing command -v wouldn't which <linter> || where <linter> work better?

edit: NM... I understand now: https://stackoverflow.com/a/677212

[wingrunr21]

Hi everyone,

Thanks for your patience. Microsoft is going to push v1.26.1 which should handle the SIGPIPE issue in the VSCode Extension Host itself.

[wingrunr21]

Hi everyone,

Thanks for your patience. Microsoft is going to push v1.26.1 which should handle the SIGPIPE issue in the VSCode Extension Host itself.

[andrewmcodes]

Anyone still experiencing this issue? I have not seen this issue since the latest updates to VS Code and feel like we could close this issue.

[andrewmcodes]

Anyone still experiencing this issue? I have not seen this issue since the latest updates to VS Code and feel like we could close this issue.

[Jesterovskiy]

Agree, from the last update - everything is fine

[Jesterovskiy]

Agree, from the last update - everything is fine