vscode: Extension host terminated unexpectedly after 1.26.0 update

I’m having the same issue. It seems to be killing prettier and possible other extensions.

In my case the Go extension make the problem, but the Go extension author is microsoft.

It looks like the root cause is https://github.com/electron/electron/issues/13254. We have identified a simple workaround to avoid the crash.

❗️❗️❗️ Please verify this issue on all 3 platforms: windows, linux and mac.

To verify, you can use the following extension:

56387-0.0.1.vsix.zip

• package.json:

{
    "name": "56387",
    "version": "0.0.1",
    "publisher": "alex",
    "engines": {
        "vscode": "^1.25.0"
    },
    "activationEvents": [
        "onCommand:extension.sayHello"
    ],
    "main": "./extension",
    "contributes": {
        "commands": [
            {
                "command": "extension.sayHello",
                "title": "Hello World"
            }
        ]
    }
}

• extension.js:

const vscode = require('vscode');
const cp = require('child_process');

exports.activate = function(context) {
    let disposable = vscode.commands.registerCommand('extension.sayHello', function () {
        console.log(`in repro1`);
        const child = cp.spawn(`/node1`);
        child.stdin.write('hi standard in!');
    });
    context.subscriptions.push(disposable);
}

same issue here, the ruby-extension is the killer in my case…

Sorry about that! It looks like there are a few hiccups possibly caused by VSCode’s Electron update. A short list of apparently impacted extensions:

• vscode-ruby - https://github.com/Microsoft/vscode/issues/56301#issuecomment-412902267
• vscode-go - https://github.com/Microsoft/vscode-go/issues/1845
• vscode-flow-ide

If you find other impacted extensions, please try to also reach out to them directly. I am not entirely sure at this point what is the root cause.

@ramya-rao-a you appear to understand the root cause, can you please explain it more https://github.com/Microsoft/vscode-go/issues/1845#issuecomment-412953676

This is most likely related to an issue with electron throwing SIGPIPE error when passing stdin to a badly spawned process

@alexandrudima My findings were similar to what @wingrunr21 is saying above.

@wingrunr21 In vscode-go we don’t need users to provide/configure the absolute paths. The extension figures out the path itself, makes sure the file exists and returns the absolute path of the file. If the file is not found, then the command is returned. That’s why my mitigation was checking for the absolute path.

The above mitigation works for https://github.com/electron/electron/issues/13254. I am still looking into if https://github.com/electron/electron/issues/13679 has any affect on vscode-go

@sanjcho Thanks for the tip! It was the same for me, disabling vscode-flow-ide fixed things. I uninstalled it and installed Flow Language Support instead.

@alexandrudima

In my investigations for vscode-ruby it appears to be when spawn is attempted to be run with a command that isn’t in the PATH and something is attempted to be piped to stdin. Since the command is invalid there’s no valid file descriptor and Electron bombs. Instead of returning ENOENT, SIGPIPE is triggered which brings down the entire extension host.

I’ve found two open Electron issues related to this: electron/electron#13254 and electron/electron#13679

As it is occurring within Electron, I haven’t found a way to prevent it from occurring at the extension level. vscode-go appears to have mitigated this by requiring the command be an absolute path prior to attempting to run it. That solution is a bit more problematic for me. I’m leaning on using a command -v check on POSIX compliant systems vs requiring users to configure absolute paths.

@mickeygo Yea they are aware of the issue: https://github.com/Microsoft/vscode-go/issues/1845

met the same, in my case disabling vscode-flow-ide extention made all working ok.