microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
162.13k stars 28.52k forks source link

macOS - Code unusable: "The window has crashed (reason: 'crashed', code: '5')" (2023-02, v1.75.1) #175581

Closed philippefutureboy closed 1 year ago

philippefutureboy commented 1 year ago

Related to: #132792

Does this issue occur when all extensions are disabled?: Yes

Steps to Reproduce:

  1. Kill any outstanding Code-related processes using Activity Monitor
  2. Clean uninstall VSCode (following this answer: https://stackoverflow.com/a/47561948/4442749)
  3. Restart computer
  4. Download VSCode universal darwin app from https://code.visualstudio.com/download
  5. Unzip installer; move VSCode universal app to the Application folder
  6. Double click the VSCode icon
  7. Cry:

Screen Shot 2023-02-27 at 3 39 56 PM

Attempted steps:


Can you link me to a few versions previous to 1.75.1? I can test them to see if I can get one to work

rzhao271 commented 1 year ago

I'm unable to reproduce the issue. Previous versions to test can be found on release notes pages, such as at https://code.visualstudio.com/updates/v1_74. If the program continues to crash, could you continue trying https://github.com/microsoft/vscode/wiki/Native-Crash-Issues to see if a dmp file is generated? You might have to wait for code to crash, and then press Close, before searching for the file.

philippefutureboy commented 1 year ago

Hi @rzhao271! Thanks for the quick answer 😃

Version 1.74.1

image

Version 1.73.1

But then, I attempted running code --crash-reporter-directory ~/some/directory and vscode crashed with the same error. Further restarts via either code or the universal executable result in the same crash loop. Good news is, I have dmp files for the first and second runs. Here is the gist: https://gist.github.com/philippefutureboy/f695c8f3a703bd4bb27497b896613efe

The files names are prefixed with 1__ and 2__ to symbolize the crash order.

Let me know if you need anything more. Progress :D

philippefutureboy commented 1 year ago

Additional context that may be relevant (or just too much info):

TL;DR: My GPU is not always stable, and that may play a part in this.


rzhao271 commented 1 year ago

Thanks for the info! I hope to symbolicate the crash dumps later today, but I'm also wondering whether running code --disable-gpu works better?

rzhao271 commented 1 year ago

I just noticed the gists actually have the logs. I'm wondering if you could upload the dmp files instead? I have access to some more symbols, so I can get more detailed logs going. Also, can you remind me what Electron version 1.73.1 uses? You can find it by going to Help > About.

philippefutureboy commented 1 year ago

RE progress:

I played around with the different conditions:

And so my primary observation is that VSCode crashes only once a workspace (repository) has been loaded, exited, then restarted.

Any other variable seems to be independent from the crash.

Any idea why that would be the case? Any steps I can take to gain further information? If I can remove the state that says which workspace to load at start, I can test what happens post-crash if the workspace is not opened at launch.

RE dumps:

It seems like the Gists don't support binary files, so I uploaded the dumps and logs to the following Google Drive directory: https://drive.google.com/drive/folders/1WeUVsM4FO5I8e9TLPnQxd6e37mkQ_DZ0?usp=sharing

RE code --disable-gpu:

Side note: v.1.73.1 has kept all of the extensions & remembers recent workspaces through reinstall even though I ran the following:

rm -rf "~/.vscode"
rm -rf "~/Library/Saved Application State/com.microsoft.VSCode.savedState"
rm -rf "~/Library/Preferences/com.microsoft.VSCode.plist"
rm -rf  "~/Library/Preferences/com.microsoft.VSCode.helper.plist"
rm -rf "~/Library/Caches/com.microsoft.VSCode"
rm -rf "~/Library/Application Support/com.apple.sharedfilelist/com.apple.LSSharedFileList.ApplicationRecentDocuments/com.microsoft.vscode.sfl*"
rm -rf "~/Library/Application Support/Code"

Are there other folders or files I should delete when doing a clean reinstall? If so let me know and I'll update the stackoverflow answer on how to uninstall vscode.

RE v1.73.1 - electron version

Version: 1.73.1 (Universal) Commit: 6261075646f055b99068d3688932416f2346dd3b Date: 2022-11-09T02:08:38.961Z (3 mos ago) Electron: 19.0.17 Chromium: 102.0.5005.167 Node.js: 16.14.2 V8: 10.2.154.15-electron.0 OS: Darwin x64 21.6.0 Sandboxed: No

rzhao271 commented 1 year ago

Thanks for the info!

Symbolicated traces: first-symbolicated.log second-symbolicated.log

Something interesting that showed up is the dmp files actually required symbols from Electron v19.1.9 to symbolicate, instead of v19.0.17. Code v1.75.1 uses v19.1.9 so I wonder whether the dmp files just finally managed to show up.

One way to try reproducing the issue with a fresh environment is to use a custom user-data-dir like so:

mkdir freshu
mkdir freshe
code --user-data-dir=freshu --extensions-data-dir=freshe

I don't think you need a custom extensions data dir if you're already running with extensions disabled, but I added it in just in case.

deepak1556 commented 1 year ago

Something interesting that showed up is the dmp files actually required symbols from Electron v19.1.9 to symbolicate, instead of v19.0.17.

Updates were not disabled after installing 1.73 so application was updated to 1.75 before the crash happened.

Looks like a crash during deserialization of code cache, @philippefutureboy does the crash repro when you launch with --no-cached-data ?

philippefutureboy commented 1 year ago

RE: code --no-cached-data

Running with --no-cached-data results in no visible changes, except following warning:

Warning: 'cached-data' is not in the list of known options, but still passed to Electron/Chromium.

There seems to be an issue in parsing the flags; plus --no-cached-data is not listed in flags when running code --help

RE: Automated updates

As @deepak1556 pointed out, v1.73.1 seems to update automatically to v1.75.1 after a few minutes. To confirm this, I ran code --version && code {{args}} for each test, and I confirm that v1.75.1 auto installs and then code starts failing.

An interesting information is that I need to quit the app in the dock before the crash starts. So, anything done within v1.73.1 is fine; v1.75.1 results in app crashing only following quitting the app in the dock and restarting. I hypothesize that some data must corrupt between the first v1.75.1 run and the second run.

Additional info - list of extensions installed

code --list-extensions
4ops.terraform
bastienboutonnet.vscode-dbt
dbaeumer.vscode-eslint
dsznajder.es7-react-js-snippets
henriblancke.vscode-dbt-formatter
ms-azuretools.vscode-docker
ms-python.isort
ms-python.python
ms-python.vscode-pylance
ms-toolsai.jupyter
ms-toolsai.jupyter-keymap
ms-toolsai.jupyter-renderers
ms-toolsai.vscode-jupyter-cell-tags
ms-toolsai.vscode-jupyter-slideshow
samuelcolvin.jinjahtml
xabikos.JavaScriptSnippets
rzhao271 commented 1 year ago

I don't think the issue has to do with the extensions if it still occurs even when the extensions are disabled. I'm wondering if the issue is fixed when using the Exploration build? It uses a newer version of Electron.

philippefutureboy commented 1 year ago

Just to keep the thread fresh - I'll be trying the exploration build by Tue evening (EST time)! For now I fixed my vscode version to 1.73.1 and downgraded extension versions to matching versions.

philippefutureboy commented 1 year ago

@rzhao271 Sorry for the delay in my answer - life got in the way.

I confirm that the Exploration build seems stable.

So for now I guess that my best choice is to stick with 1.73.1 (disable updates and extension updates) and wait for the current version of the Exploration build to merge in the main distribution?

philippefutureboy commented 1 year ago

Marking as closed, since I have a stable version running (1.73.1) and will be able to migrate to the exploration build in due time.