v1.90.0 snap COMPLETELY STOPPED WORKING AND WON'T STAY OPEN

[geekley]

Describe the bug
After the latest update, snap codium v1.90.0 won't stay open.
It closes immediately after opening without any sort of crash message or any message at all.
I've also tried with codium --disable-extensions, same thing.

Please confirm that this problem is VSCodium-specific
The flatpak I have for MS VSCode didn't update to 1.90.0 yet, so I'm not sure I can confirm this yet.

Please confirm that the issue/resolution isn't already documented

• I checked the Docs page and the Troubleshooting page and my issue is not mentioned there.

To Reproduce
Steps to reproduce the behavior:

1. Just try to open the app in any way

Expected behavior
It works, or at least should give me a crash message or log describing the problem.

Versions:
codium snap v1.90.0 cc102f3a62bd35f39ed059b99c5cce90e50a16e2
Operating System: Kubuntu 24.04 LTS x64
KDE Plasma Version: 5.27.11
KDE Frameworks Version: 5.115.0
Qt Version: 5.15.13
Kernel Version: 6.8.0-35-generic (64-bit)
Graphics Platform: X11
Graphics Processor: Mesa Intel® HD Graphics 5500

Additional context
Was working fine just yesterday. I didn't do anything different, just had snap update.
If there's any sort of log I can provide, please tell me where I should find it.

[daiyam]

Ok, I've reverted the snap the 1.89.1.24130.

[daiyam]

If there's any sort of log I can provide, please tell me where I should find it.

You can do codium --verbose

[geekley]

OK I tried running codium --disable-extensions --log trace --verbose and got WAY too much info on the console.
There seems to be several errors mentioned, but since it's so much info, I'd rather send you that privately.
Can I just email you that log?

[geekley]

Thanks! After doing a snap refresh, it downgraded and it's working.
I sent that log to the email in your profile.

[daiyam]

It seems to be a driver issue.

libGL error: MESA-LOADER: failed to open iris: /usr/lib/dri/iris_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)
libGL error: failed to load driver: iris
libGL error: MESA-LOADER: failed to open iris: /usr/lib/dri/iris_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)
libGL error: failed to load driver: iris
libGL error: MESA-LOADER: failed to open swrast: /usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)
libGL error: failed to load driver: swrast
[6623:0606/181317.566496:ERROR:angle_platform_impl.cc(44)] Display.cpp:1052 (initialize): ANGLE Display::initialize error 12289: Could not create a backing OpenGL context.

There is already a bug related to the Iris driver with snap (#1814)

[shelvesdragon]

Hey, over on the MS version of VSCode, there is a related issue, see: microsoft/vscode#212494

The workaround is to launch code with code --use-gl=angle --use-angle=swiftshader, so my suggestion would be to try and launch codium with:

codium --use-gl=angle --use-angle=swiftshader

The new release of the snap package of codium hasn't made through to the snap store yet, so I unfortunately cannot confirm myself yet.

[daiyam]

The new release of the snap package of codium hasn't made through to the snap store yet, so I unfortunately cannot confirm myself yet.

I did revert to the older version after the report of the issue.

[shelvesdragon]

I downloaded v1.90 from the Release page and installed it for a quick test. I can confirm it's the same issue as with code and the workaround does work as well. I get some more fan noise and additional resource usage though, but that is probably to be expected, since the flags switch to OpenGL software emulation rather than GPU cores (from what I understand).

And thanks for the revert, I switched back to v1.89.1 after testing.

[daiyam]

I will move the Insiders version to core22. It might fix the issue.

[geekley]

I get some more fan noise and additional resource usage though, but that is probably to be expected, since the flags switch to OpenGL software emulation rather than GPU cores (from what I understand).

@shelvesdragon I've read some comments from the upstream issue.
People have also said it works with code --in-process-gpu, I don't understand exactly what it does, but maybe that one wouldn't cause the excess resource usage?

microsoft/vscode#212494 (comment) also seems to indicate it might be related to external monitors on a laptop. In my case crash happened on laptop with external monitor connected via DisplayPort (in "extend" mode), I didn't test without the external monitor, nor in "unify outputs" mode.

I will move the Insiders version to core22. It might fix the issue.

@daiyam Would that be without any extra flags? Btw, from microsoft/vscode#212494 (comment)
It seems upstream should fix it on both 1.91.0 and 1.90.1: microsoft/vscode#214560
Or rather, not "fix" but workaround it by including the flags on snap. Though I really hope they find a solution that doesn't require software emulation or cause excess resource usage.

EDIT: indeed it's a temporary workaround:

For those interested in following, I am continuing the investigation in microsoft/vscode#214830 and will land a proper fix as a follow-up.

[shelvesdragon]

People have also said it works with code --in-process-gpu, I don't understand exactly what it does, but maybe that one wouldn't cause the excess resource usage?

Unfortunately, I got about an equal amount of additional resource usage with both variants. However, trying to reproduce just now, same workspace, same editors opened, I didn't get any additional fan noise and only slight additional CPU usage. Comparing codium in v1.89 and Code in 1.90.0 I do get a less smooth scrolling experience in code v1.90, as if every other frame is dropped and the previous frame just stays twice as long. It's not much and not particularly disturbing, but noticeable if you know it's there. The main difference between the initial test and now is probably that I'm currently not plugged into wall power, so it could be a CPU power usage constraint or less heat from not charging the battery, or both. Then again, I consider my laptop to be fairly decent, so for others with less resources this could potentially be a problem...

Laptop is a Tuxedo Aura 15 Gen 2, with:

• CPU: AMD Ryzen 5 5500U with Radeon Graphics (6 Core, 12 Threads)
• RAM: 16 GB DDR4
• OS (lsb_release -a): Tuxedo OS 3/Release: 22.04/jammy (basically kubuntu with custom color themes, custom apt repos, custom list of pre-installed software)
• Drive: Kingston 250 GB NVMe drive (M.2 PCIe 3.0 x4 interface)

I don't fully understand what is happening either but from this list of command line flags for chromium: https://peter.sh/experiments/chromium-command-line-switches/ it seems that --in-process-gpu moves the GPU hardware acceleration to a thread of the main process rather than starting a separate process. From The Chromium Project's article "GPU Accelerated Compositing in Chrome", https://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome/

Before we go any further exploring the GPU commands the compositor generates, its important to understand how the renderer process issues any commands to the GPU at all. In Chrome’s multi-process model, we have a dedicated process for this task: the GPU process. The GPU process exists primarily for security reasons. [...]

Restricted by its sandbox, the Renderer process (which contains an instance of Blink and of cc) cannot directly issue calls to the 3D APIs provided by the OS (GL / D3D). For that reason we use a separate process to access the device. We call this process the GPU Process.

From https://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome/

This could mean that --in-gpu-process, while fixing the issue, circumvents the sandboxing aspect and is potentially less secure, as suggested on reddit: https://www.reddit.com/r/Gentoo/comments/yu2s3j/psa_chrome_based_browsers_nvidia_wayland_and_full/ . It could also just mean that chromium can now verify it has no gpu for hardware acceleration and switch to some sort of software emulation on its own.

The flags --use-gl=angle --use-angle=swiftshader switch to OpenGL emulation on the CPU, but to the other parts of the software that use the hardware acceleration interface, it seems as if the hardware acceleration still happens on the GPU, see: https://chromium.googlesource.com/chromium/src/+/refs/tags/99.0.4772.1/docs/gpu/swiftshader.md and this thread: https://groups.google.com/a/chromium.org/g/graphics-dev/c/CpVms3tXRhk
I haven't been able to figure out what this means for the separate process and chromium's GPU-access sandboxing.

With --in-process-gpu, one commenter reported freezes. So far, I haven't been able to reproduce those freezes: microsoft/vscode#212494 (comment)

• code --in-process-gpu does not crash, but the window often freezes, so that I have to bring it down manually and restart

[geekley]

IMO, instead of updating snap codium to 1.90.1, it might be safer to wait a little until the actual fix (i.e. when microsoft/vscode#214830 is resolved). Unless it takes too long, (e.g. > 1 month), then it may be better to just update to the workaround.

[daiyam]

Ok, the fix 1.90.1 is to switch to the software gl backend (microsoft/vscode#214549) but it's slow down VSCode.

Per microsoft/vscode#214830, the issue seems to be regression in Chromium (fixed the 8th Dec 2023) so the real fix will, I think, in 1.91.0 when they will update to a newer electron version.

I think it's better to wait for the real fix.

[shelvesdragon]

Just wanted to check back on this, because there's news:

• the root cause of the crashes is explained in 1.90 snap package crash on startup  microsoft/vscode#212494 (comment)
• the temporary workaround was to revert the snap version to revision 159/1.89.1 or 160/1.90.0 depending on whether there were crashes with 160/1.90.0 or crashes/lag with 161/1.90.1 1.90 snap package crash on startup  microsoft/vscode#212494 (comment)
• there is a candidate build that solved both the crashes of 1.90.0 and the lag issue of 1.90.1, at least for me and a few others. The build is linked in the comment just below the previous one 1.90 snap package crash on startup  microsoft/vscode#212494 (comment)
• the fixes of the candidate build will be shipped with the 1.90.2 release that seems to come later this week 1.90 snap package crash on startup  microsoft/vscode#212494 (comment)

[daiyam]

The 1.90.2.24171 is available on the edge channel. I will wait for your feedbacks before promoting it to stable. Thx

[shelvesdragon]

I've switched to the edge channel, snap list codium returns:

Name    Version       Rev  Tracking     Publisher  Notes
codium  1.90.2.24171  398  latest/edge  vscodium   classic

Unfortunately, VSCodium on the edge channel still crashes on startup. I've checked the changes in (Edit: one of, the one to release/1.90, the other one to main PR #216661 did not highlight the changes, version in package.json is 1.91.0) the pull request related to issue microsoft/vscode#212494 in VSCode (PR #215954) and compared them to VSCodiums insiders snapcraft.yaml and the stable snapcraft.yaml.

In section stage-packages, three libraries were added to VSCode's snapcraft.yaml. Those are still missing from VSCodium's insider snapcraft.yaml (in the stable snapcraft.yaml file as well, as expected). The gl in the names suggests that those libraries might be OpenGL/graphics related:

diff --git a/resources/linux/snap/snapcraft.yaml b/resources/linux/snap/snapcraft.yaml
index ???????..40c845e 100644
--- a/resources/linux/snap/snapcraft.yaml
+++ b/resources/linux/snap/snapcraft.yaml
@@ -22,30 +22,33 @@ parts:
      - libcurl3-gnutls
      - libcurl3-nss
      - libcurl4
+      - libegl1
      - libdrm2
      - libgbm1
      - libgl1
+      - libgles2
      - libglib2.0-0
      - libgtk-3-0
      - libibus-1.0-5
      - libnss3
      - libpango-1.0-0
      - libsecret-1-0
+      - libwayland-egl1
      - libxcomposite1
      - libxdamage1
      - libxfixes3

Maybe this is why the crashes are still there for VSCodium 1.90.2.24171?