Extension host terminates unexpectedly on 1.53 Insider with opened workspace folder.

[3b0b]

Version: 1.53.0-insider
Commit: f3e95ede9e4b9818c29a5bca3564d6fd162fb210
Date: 2020-12-15T08:23:08.890Z
Electron: 11.0.5
Chrome: 87.0.4280.88
Node.js: 12.18.3
V8: 8.7.220.29-electron.0
OS: Windows_NT x64 10.0.21277

All installations in portable mode - have not tested non-portable.

Tried disabling all other extensions; still crashed.

Tried a fresh copy of 1.52 (current stable); no crash.

Tried a fresh copy of 1.53 just to make sure nothing lingering from my regular installation was still causing the problem despite disabling everything else, and the crash occurs.

If no connections are opened as workspace folders, the extension host doesn't crash. It crashes on trying to open one, or on startup if I had one open already.

I realize you might not support the insiders edition, but since I am not sure how to ascertain whether this is caused by a bug in Insiders that they might fix or an intentional breaking change, I thought I had better report it.

[SchoofsKelvin]

I've tried reproducing this, without success:

• Downloaded the .zip for version 1.53.0 for Insiders
• Extracted it and added a data directory as mentioned here
  (this folder actually gets filled, so I assume it is running in portable mode)
• Installed the extension (v1.18.3), added a configuration and added it as Workspace Folder
• Reloaded with the connection still active. Reload went fine, everything works fine

Seems to be I'm using, as expected, a later commit though:

Version: 1.53.0-insider
Commit: 2f8dee4d87cf215fd2ece45aa4ecfb097b345788
Date: 2020-12-16T10:01:14.499Z
Electron: 11.0.5
Chrome: 87.0.4280.88
Node.js: 12.18.3
V8: 8.7.220.29-electron.0
OS: Windows_NT x64 10.0.18363

Although I don't immediately see something regarding crashes.

I assume it was a broken Insiders build. Closing this issue for now.

[3b0b]

Yep, works for me now too. Shame they didn't fix it earlier in the week before I got worried enough to submit an issue.

[3b0b]

Well, now it's happening to me again...including with my backup of 2f8dee4d87cf215fd2ece45aa4ecfb097b345788 and a fresh installation. Not sure if I messed up my test yesterday and it was never working for me, or if I'm just special.

I'm sticking with 1.52.0 for a while because I need it working for now. I will remark that based on the timing, the extension output, and the vscode console logs, it looks like the crash was happening after ignoring FileNotFound errors for .vscode/settings.json (and tasks, and launch, and extensions, and a git config) in the workspace folder, and before encountering a "No such file" error for .devcontainer/devcontainer.json. If it's still happening on an up-to-date Insiders the next time I have a chance to poke at it, I'll actually try to have the presence of mind to provide logs next time.

[SchoofsKelvin]

Those errors are kind of normal. Whenever a workspace folder gets added, VS Code and some extensions start checking for files. E.g. it checks for stuff in .vscode, I've had a Maven plugin check pom.xml, the Git extension for .git, ....

The "ignoring" part comes from here and here. Instead of logging a full blown error with Logging.error (which outputs e.g. a partial stacktrace), it just uses this.logging.debug for a simple one-liner mention.

[3b0b]

I should probably have made it more clear that I was pretty sure what was going on with those was intentional.

I have progressed to new and exciting further levels of bafflement: the crash seems to depend on both the VSCode version and the SSH host.

It is unsurprising to me that the crash can be demonstrated not to happen if the connection fails due to authentication not working. Given that, it also does not surprise me that key vs password auth seems to make no difference.
What I have no explanation for currently is that the crash only occurs for the RHEL 6 hosts for which I most frequently want to use it (the main one is 6.3, I think another is 6.4), and not for a RHEL 7 host I had available that I don't really have any reason to use this extension for.

On the bright side, that may mean that if my sysadmin and I can ever get enough time to replace or upgrade the key RHEL 6 machine in question, this won't be an issue for me anymore...

P.S. Good luck with your exams!

[SchoofsKelvin]

I've noticed you mentioned this in microsoft/vscode#114362:

The crash seems to happen - I think - during the check for various potential configuration files in the workspace folder (.vscode, .git, .devcontainer, etc.), but I don't know whether those are causing it or if the timing might be coincidental.

If your project contains these directories, try copying them (exactly) to another host and see if it happens there too, in case it's something in the files. Maybe a weird byte in .vscode/tasks.json or so might cause it.

Alternatively, you can "develop" the extension, change readDirectory and/or stat and such to make VSCode think the files/directories don't exist, to narrow down further what causes the crash.

With it happening on different extensions but with the same host, I'd imagine it might be an issue with the SSL library (NodeJS in) VS Code uses or something similar. An extension just throwing errors shouldn't result in the whole extension host crashing.

[3b0b]

I'll have to take another crack at that later. So far I can't figure out how to "develop" the extension correctly. I think once I figure out where the missing "react-scripts-ts" command is supposed to have come from I might be pretty close.

Nothing I'm doing actually has any of the files or directories it's looking for; there's no project or workspace configuration involved, let alone a remote workspace. All I use this for is a convenient way to edit a couple of remote scripts.

[SchoofsKelvin]

I've actually refactored the webview part and removed react-scripts-ts entirely from it. I just pushed the change to the master branch.

In theory, after checking out the branch, launching VS Code, giving a minute to build (assuming you've said yes to the "run tasks on folder open" thing), and pressing F5 to launch the extension, it should be useable. Only thing you have to remember is that when you change some code, you need to save, wait for it to build, then ctrl+r (shortcut for Developer: Reload window) in the "dev window" so it can actually use the changed code.

Once my exams are over, I'll see if I can run RHEL 6.3 VM and reproduce the bug. Not sure how well that'll go, as the extension host crashing should be something beyond my extension's scope.

[3b0b]

Well, with that advice, after a bunch of caught exceptions (mostly from the built-in git extension), which I finally figured out I could uncheck "caught exceptions" instead of clicking past, I have successfully determined that...it gets to the point of logging

[INFO] [createSSH(sftp-test)] Creating SSH session over the opened socket

and then before reaching the point where when it works (whether because I'm running 1.52.0, or because I'm connecting to something other than RHEL 6) it would log

[INFO] [getSFTP(sftp-test)] Creating SFTP session using standard sftp subsystem

..the debugging session just ends, and the Extension Development Host window asks me whether I want to save my workspace to a file. No uncaught exception to break on in the debugger, no message from the Development Host that the extension host has crashed and would I like to restart it.

I think my next step is going to be seeing if I can put a breakpoint where that last successful log message happens, and then either re-enable breaking on caught exceptions before I resume, or just plain start stepping forward from that point.

[SchoofsKelvin]

Any news on your side? With the stable release of 1.53.0, this issue suddenly seems a lot more widespread: #239

I'm assuming both issues are the same, so I'll keep this one closed and continue in the new non-Insider-aimed issue.

[3b0b]

I haven't been able to get back to it, let alone with enough time to try to sift through a bunch of break-on-X that I don't really understand. I'll try to keep up via the newer issues as well.

[danhogan]

Just thought I'd add that the latest VSCode version broke the extension for me as well. On Windows 10 connecting to RHEL 6.10.

[chrisfinnigan-S1]

Also having issues with VSCode 1.53 on Ubuntu 18.04 and Mac. I have had to roll back to 1.52 and everything works fine

[SchoofsKelvin]

Issue locked in favor of #239