vscode: Broken shader compilation with mesa update

  1. Workaround

    This is an issue in Chromium itself. For now there are the following two workarounds:

    1. https://github.com/microsoft/vscode/issues/190437#issuecomment-1722228671

      rm -rf "$HOME/.config/Code/GPUCache"
      
    2. https://github.com/microsoft/vscode/issues/190437#issuecomment-1679815094

      If ($IsLinux) {Remove-Item -Path "$HOME/.config/Code - Insiders/GPUCache"}
      
  2. Bug

    Does this issue occur when all extensions are disabled?
    I can’t test that.
    1. VS Code Version

      Per:

      code-insiders
      

      …the affected version is:

      Type Data
      Version 1.82.0-insider
      Commit 76985ae7814f7cb28e2df6f1025d279bb77cbec1
      Date 2023-08-11T17:10:45.392Z
      Electron 25.4.0
      ElectronBuildId 22958381
      Chromium 114.0.5735.248
      Node.js 18.15.0
      V8 11.4.183.27-electron.0
      OS Linux x64 6.4.9-1-default

      However, per:

      code
      

      …note that --channel=latest/stable, that is:

      Type Data
      Version 1.81.1
      Commit 6c3e3dba23e8fadc360aed75ce363ba185c49794
      Date 2023-08-09T22:18:39.991Z
      Electron 22.3.18
      ElectronBuildId 22689846
      Chromium 108.0.5359.215
      Node.js 16.17.1
      V8 10.8.168.25-electron.0
      OS Linux x64 6.4.9-1-default snap

      …works:

      image

    2. OS Version

      cat -vbET '/etc/os-release'
      
           8  CPE_NAME="cpe:/o:opensuse:tumbleweed:20231119"$
      
      uname -a
      
      PS /home/rokejulianlockhart> uname -a
      Linux RQN6C6 6.4.9-1-default #1 SMP PREEMPT_DYNAMIC Wed Aug  9 05:07:55 UTC 2023 (5b9ad20) x86_64 x86_64 x86_64 GNU/Linux
      PS /home/rokejulianlockhart>
      
  3. Steps to Reproduce

    1. code-insiders
      
    2. The GUI is invisible:

      image

      …yet the menubar continues to operate correctly.

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Reactions: 12
  • Comments: 53 (7 by maintainers)

Commits related to this issue

Most upvoted comments

@deepak1556 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.

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?

This issue has been fixed upstream via this Chromium commit.

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.

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.

I’d disagree, @deepak1556 . 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 #194440 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.

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.

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.

This bug has been fixed in the latest release of VS Code Insiders!

@RokeJulianLockhart, you can help us out by commenting /verified if things are now working as expected.

If things still don’t seem right, please ensure you’re on version 54821ee1f14beca4866abd7de86175b4794b030d of Insiders (today’s or later - you can use Help: About in the command palette to check), and leave a comment letting us know what isn’t working as expected.

Happy Coding!

Is there a linked Electron issue for this?

I haven’t found any linked Electron issues yet.

Do we need to create one if not or does the Electron project accept drive-by backport PRs?

Based on this document, 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 patches/chromium/ directory and append the filenames of said patch files to the .patches file.

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.

Also ran into this, thanks for this workaround, it worked.

rm -rf "$HOME/.config/Code/GPUCache"

@deepak1556 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

For what it’s worth, I haven’t encountered it on the rpm again

https://github.com/microsoft/vscode/issues/190437#issuecomment-1836601231

@andreamah, 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).

This has happened a second time in 1.83.1.

Leaving this here for future me, as I now have that problem on a different PC

rm -rf ~/.config/Code/GPUCache

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.

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.

@rokejulianlockhart I see many GPU-related errors, such as: Errors: link failed but did not provide an info log [3007:0815/155508.112542:WARNING:angle_platform_impl.cc(48)] ProgramGL.cpp:989 (checkLinkStatus): Program link or binary loading failed with no info log. [3007:0815/155508.112636:ERROR:shared_context_state.cc(81)] Skia shader compilation error

Found these: https://bugs.chromium.org/p/chromium/issues/detail?id=1442633 https://github.com/ferdium/ferdium-app/issues/1265 https://bbs.archlinux.org/viewtopic.php?id=285507 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.