Code change:
Workaround This is an issue in Chromium itself. For now there are the following two workarounds: ### <blockQuote</blockQuote1. ### <blockQuote</blockQuote## Bug <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. -- <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --1. ### VS Code Version Per: affected version is: <blockQuoteType | Data ----------------|----------------------------------------- Version | 1.82.0-insider Commit | Date | 2023-08-11T17:10:45.392Z Electron | 25.4.0 ElectronBuildId | Chromium | 114.0.5735.248 | 18.15.0 V8 | 11.4.183.27-electron.0 OS | Linux x64 6.4.9-1-default </blockQuoteHowever, per: that , that is: <blockQuoteType | Data ----------------|----------------------------------------- Version | 1.81.1 Commit | Date | 2023-08-09T22:18:39.991Z Electron | 22.3.18 ElectronBuildId | Chromium | 108.0.5359.215 | 16.17.1 V8 | 10.8.168.25-electron.0 OS | Linux x64 6.4.9-1-default snap ### OS Version <blockQuote</blockQuote</details## Steps to Reproduce 1. The GUI is invisible: the menubar continues to operate correctly.
82 updated to Electron 25 and doesn't work on older OS.
I'm using cpe:/o:opensuse:tumbleweed:, which updated 2600 packages yesterday (which I have installed) yet this problem remains. Nobody in their right mind would consider that to be old. Additionally, I am using which means that no independent part of the OS should be considered old. This is the most bleeding edge system for miles. Regardless, should I perhaps open a linked issue at
Oh, sorry, I thought it's an old OS issue. Before reporting in the electron repo, what is Help Toggle Developer Tools bringing up? Have you tried to do a clean reinstall of VSCode Insider? Perhaps it was just a bad build. Or, alternatively, you could try to download the latest Insider installer and install over your existing broken version (which I assume it's 3-4 days older than what you'd get right now) - that should effectively update it.
No problem. Thanks. Apologies for being curt. ! ! Appears that it's reproducible.
Very strange, indeed. I'm out of ideas. Would be interesting to be able to test with a previous Insider version, but for that you would need to have the old package and disable automatic updates. Electron was updated from 22 to 25 on August 8, so the last version with Electron 22 is the Insider from August 7, which is also the last version that I've tested and still working on Windows 7. Anything after that doesn't start anymore on Win 7. I'm not sure whether the Electron update on August 8 is causing your issue, though...
does the log file explain anything? To me, it seemed a little too verbose to be of much use. I can try other methods to get relevant diagnostic data if you are able to instruct me.
I see many GPU-related errors, such as: Errors: link failed but did not provide an info log [(48)] (checkLinkStatus): Program link or binary loading failed with no info log. [(81)] Skia shader compilation error Found these: So it's definitely something related to the new Chromium included in Electron 25 and these issues seem relatively recent. The first link recommends to disable hardware acceleration, you could try searching how to do that from command line in the new Insider. Unfortunately, I don't have the time to dig deeper right now.
per , do you know whether VSCode contains a directory? I haven't been able to locate it.
remediates the problem. Because indeed this issue is dependent upon , before this update is rolled out, there needs to be remediating measures (or the update needs to be temporarily halted) lest it break a great many peoples' installations.
Can you please take a look at this? It's Chromium/Electron 25 related, so I immediately thought of you. Please see the response just above for a possible solution. Thanks!
Thanks for investigating the issue, given there are workarounds in place this is not necessarily a release blocker. I will wait for chromium to address this issue and backport the fix to Electron 25.
could a patch at least be to the affected releases to delete the relevant directory? Surely users shall be affected otherwise? I doubt we can expect them to diagnose a known issue if the solution is so simple.
We don't want to delete the GPUCache for all users and the affected scenario described in is not possible to detect from the application layer. I think the best I can do is to add this issue to the release notes and document the workarounds for visibility.
Why?
It will have impact on startup performance, for now I would wait to see the impact of this issue across our users and decide on a fix forward. The upstream issue has also been open for a while now, signifying its low impact.
Just happened again. !
This is mentioned in the 1.82 release notes I guess the issue remains in 1.83-insiders, haven't tried it yet.
It appears weird to me that solely VSCode appears to be affected by this (on my system) because Discord has been very happily updating frequently, and obviously has its own Electron-provided directory. !
Related on Stack Overflow: Related on Reddit: ,
Got this installed via fedora yesterday This wasted quiet some time on my end, as I first went searching for changes to fedora itself and finding this issue on vscode wasn't trivial.
Leaving this here for future me, as I now have that problem on a different PC
This also happens for other Electron based programs like Element and also chromium and firefox. see
I'd disagree, . It doesn't read like pragmatism - more like "didn't want to do a good fix". Startup time after the workaround felt normal. Super aggravating that this wasn't resolved with a one-time installation task to clear the GPU cache. Hard to know the aggregate cost incurred by people encountering this issue, but "not small" is probably an underestimation. Linked-issue count wouldn't be a good proxy for that metric, in that product-support's practice as shown in seems to be linking to the known-issue buried in the release notes, not to this issue. Sorry for the flames, but there you have it. When one's coding environment gets fsck'd, it's no fun, and erodes trust. Please consider.
I, for one, find great enjoyment in my coding environments.
This issue has reemerged with the latest version 1.82.3 for Ubuntu 20.04.1: Removing after the upgrade still works to get vscode running
It occurs for me almost every update of the package. It's ridiculous.
Same.
As mentioned before, this is caused by the new update in VSCode I have personally reverted to until this issue is properly solved
I was under the impression from the chromium bug that this is one time change and not required for every startup. I see that you are using snap version of VSCode, can you check if you are required to delete the cache for every start using the instead ?
I must rectify my comment: with the snap of version v1.82.1, it was required to clear the cache every startup, with v1.82.2 I don't remember having to do it, while with v1.82.3 it was needed only once on upgrade. I will edit my previous comment to fix it.
We had a runtime version bump between to , which seems like a trigger in the snap case. Can you setup deb package, we will have release this week. It would be good to confirm if updating requires to clear the cache in the deb package as well.
For what it's worth, I haven't encountered it on the rpm again
I've tried the following: removing v1.82.3 (snap) and installing v1.82.3 (deb) did require clearing the cache. removing v1.82.3 (deb) and installing v1.82.2 (deb) did not require removing the GPUCache. upgrading v1.82.2 (deb) to v1.82.3 (deb) using apt did not require removing the GPUCache. hope it helps
I'm not using the snap any more. I use the package provided directly by Microsoft from
Encountered this problem on Fedora 39, probably after upgrading my vscode rpm which is currently on version 1.82.3. Problem disappeared after running .
Not with VSCode specifically: but when updating to electron v28 alpha, had this issue. Also solved with (or just deleting the entire Electron dir within ).
Also ran into this, thanks for this workaround, it worked.
I also ran into the issue in VSCodium (which is a special build script for this source code) after an upgrade to 1.83.1 on Debian Trixie and XFCE 4.18. The worked like a charm (which is the equivalent folder on Debian for VSCodium). I did find that I only ran into the issue on my RX 550 (Lexa) and not my Radeon RX 580 (Polaris); I found that the bug disappeared when running the program with appended to it to run it on the latter graphics card.
This has happened a second time in 1.83.1.
Got it again on fedora using the rpm on a system, where I already dropped the cache once Version 1.83.1
Just installed an update with no vscode update but had a mesa update. VSCode broke again. I assume this is going to happen every time a mesa update is installed (I'm assuming because of what others are stating, could be something other than mesa but seems to be the biggest suspect).
Getting it after every mesa update. But may be "GPUCache" need some harder refresh or detection of brockage?
This issue has been fixed upstream via . It might take a while before it trickles downstream though, since it needs to be picked up by Electron first before it can go into VSCode. I did attempt cherry-picking the commit and generating a local build and it seemed to fix the issue.
The commit is fairly trivial and can probably be safely backported to all supported Electron trees. This is a very widespread issue, affecting virtually every Electron app running on Linux. It would be great to get the fix as widely disseminated as possible considering how slow the app ecosystem is to update versions. Is there a linked Electron issue for this? Do we need to create one if not or does the Electron project accept drive-by backport PRs?
I haven't found any linked Electron issues yet. Based on , since the patch is temporary, has been committed upstream, and will eventually be removed, I think the Electron folks will accept the patch. However, do take note that the commit has dependencies on previous commits. On my working local build, I have these 3 commits cherry-picked in chronological order: Therefore, if anyone is going to bring this up to the Electron team, all 3 patches would need to be merged. Add the patch files to the and append the filenames of said patch files to the . Depending on the Electron build version, there might also be some merge conflicts. Based on my experience, those conflicts should be resolvable, but I did not test all of the older Electron major version release branches. For each branch, we would need to double-check if the 2 dependency commits are already included in their respective Chromium version or not.
Thank you for the backporting work to Electron versions 25-28 over the past few days. Downstream applications should now be able to pick those fixes up. Once VSCode picks up the fix, we should be able to close this issue.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
I'll verify when the next release reaches me on openSUSE.
by chance, were you able to verify the fix for the issue yet?
the time period hasn't been quite long enough to be certain. This usually occurs on an update or after approximately two months. However, VSCode did update recently, and this didn't occur (not that it was guaranteed). Consequently, if upstream has fixed the issue, and we're using the patched version, because it hasn't appeared yet, I'll keep this completed until it occurs (and we can reasonably consider this complete).
Considering the issue as verified on 1.85.x. 1.86.0 will go out in around a week. Feel free to comment on this issue thread if the issue comes up again after that.

Related discussion:
text: resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.207.tgz#9c3310ebace2952903d05dcaba8abe3a4ed44c01" integrity sha512-piH7MJDJp4rJCduWbVvmUd59AUne1AFBJ8JaRQvk0KzNTSUnZrVXHCZc+eg+CGE4OujkcLJznhGKD6tuAshj5Q== <del> electron@25.9.2: version "25.9.2" resolved "https://registry.yarnpkg.com/electron/-/electron-25.9.2.tgz#12be98fbcff485c94ff99df21e0727797a45364a" integrity sha512-hVBN5rsrL99BKNHvzMeYy2PkAmewuIobu4U3o3EzVz4MDoLmMfW4yTH5GZ4RbJrpokoEky5IzGtRR/ggPzL6Fw== </del> <ins> electron@25.9.4: version "25.9.4" resolved "https://registry.yarnpkg.com/electron/-/electron-25.9.4.tgz#1935b6fbfd8ad920719a4136d867021496703884" integrity sha512-5pDU8a7o7ZIPTZHAqjflGMq764Favdsc271KXrAT3oWvFTHs5Ve9+IOt5EUVPrwvC2qRWKpCIEM47WzwkTlENQ== </ins> dependencies: "@electron/get" "^2.0.0" "@types/node" "^18.11.18"