VSCodium
v1.90.0 snap COMPLETELY STOPPED WORKING AND WON'T STAY OPEN
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
- [x] I checked the Docs page and the Troubleshooting page and my issue is not mentioned there.
To Reproduce Steps to reproduce the behavior:
- 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.
If there's any sort of log I can provide, please tell me where I should find it.
You can do codium --verbose
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?
Thanks! After doing a snap refresh, it downgraded and it's working. I sent that log to the email in your profile.
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)
Hey, over on the MS version of VSCode, there is a related issue, see: https://github.com/microsoft/vscode/issues/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.
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.
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.
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?
https://github.com/microsoft/vscode/issues/212494#issuecomment-2135429922 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 https://github.com/microsoft/vscode/issues/212494#issuecomment-2154918724 It seems upstream should fix it on both 1.91.0 and 1.90.1: https://github.com/microsoft/vscode/pull/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 https://github.com/microsoft/vscode/issues/214830 and will land a proper fix as a follow-up.
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: https://github.com/microsoft/vscode/issues/212494#issuecomment-2157940062
code --in-process-gpudoes not crash, but the window often freezes, so that I have to bring it down manually and restart
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 https://github.com/microsoft/vscode/issues/214830 is resolved). Unless it takes too long, (e.g. > 1 month), then it may be better to just update to the workaround.
Ok, the fix 1.90.1 is to switch to the software gl backend (https://github.com/microsoft/vscode/pull/214549) but it's slow down VSCode.
Per https://github.com/microsoft/vscode/issues/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.
Just wanted to check back on this, because there's news:
- the root cause of the crashes is explained in https://github.com/microsoft/vscode/issues/212494#issuecomment-2166941209
- 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 https://github.com/microsoft/vscode/issues/212494#issuecomment-2168072242
- 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 https://github.com/microsoft/vscode/issues/212494#issuecomment-2168893148
- the fixes of the candidate build will be shipped with the 1.90.2 release that seems to come later this week https://github.com/microsoft/vscode/issues/212494#issuecomment-2177372049
The 1.90.2.24171 is available on the edge channel. I will wait for your feedbacks before promoting it to stable. Thx
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 https://github.com/microsoft/vscode/issues/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?
The 1.91.x are available on the edge channel. Can you tell me if it's working? Thx
tl;dr:
- still crashes for snap 1.91.1.24193 from release page
- no new snap on edge channel according to snap, maybe accidentally forgot some step to publish?
Unfortunately, when I try sudo snap refresh codium, I get:
snap "codium" has no updates available
snap info codium prints:
name: codium
summary: Code editing. Redefined.
publisher: VSCodium
store-url: https://snapcraft.io/codium
contact: https://github.com/VSCodium/vscodium/issues
license: unset
description: |
Binary releases of Visual Studio Code without branding/telemetry/licensing
commands:
- codium
- codium.url-handler
snap-id: lIZWXTqmo6LFSts5Cgk2VPlNwtysZAeH
tracking: latest/edge
refresh-date: today at 13:52 CEST
channels:
latest/stable: 1.89.1.24130 2024-06-06 (394) 313MB classic
latest/candidate: ↑
latest/beta: ↑
latest/edge: 1.90.2.24171 2024-06-20 (398) 313MB classic
installed: 1.90.2.24171 (398) 313MB classic
and codium --version prints:
1.90.2
7d98c6de73fb939f1eb4b8a500c569b858b2d297
x64
I also tried to manually install the snap from the release page, codium_1.91.1.24193_amd64.snap though not sure if that is a different build than the 1.91.x one that is supposed to be on the edge channel. For the release page 1.91.1.24193, I still get the crash on start up with codium --verbose:
Gtk-Message: 14:08:35.080: Failed to load module "colorreload-gtk-module"
Gtk-Message: 14:08:35.080: Failed to load module "window-decorations-gtk-module"
[10742:0712/140835.181600:WARNING:bluez_dbus_manager.cc(248)] Floss manager not present, cannot set Floss enable/disable.
libGL error: MESA-LOADER: failed to open radeonsi: /usr/lib/dri/radeonsi_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: radeonsi
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
[10763:0712/140835.332546:ERROR:angle_platform_impl.cc(44)] Display.cpp:1052 (initialize): ANGLE Display::initialize error 12289: Could not create a backing OpenGL context.
...
And with codium --in-process-gpu it starts up just like 1.90.2 did, but that has the associated problems mentioned above.
no new snap on edge channel according to snap, maybe accidentally forgot some step to publish?
Ah, I need to reexport the credentials (https://github.com/VSCodium/vscodium/actions/runs/9896511794/job/27339792637#step:3:21)
though not sure if that is a different build than the 1.91.x one that is supposed to be on the edge channel.
Yes, they are the same.
OK, this time the 1.92.1.24225 is really available on the edge channel...
(The previous version wasn't published because the pub key was expired...)
Can confirm it's published, I got an update notification from snap, snap info now says the installed version and edge version is v1.92.1.24225.
The output of codium --verbose still contains several libGL related errors, e.g. still for MESA-LOADER and radeonsi driver, swrast and egl, but so far, I could not reproduce the crashes on start up for this build, so not sure if it is resolved in general or just working for my specific config and laptop:
Gtk-Message: 14:09:54.130: Failed to load module "colorreload-gtk-module"
Gtk-Message: 14:09:54.130: Failed to load module "window-decorations-gtk-module"
[8555:0814/140954.176176:WARNING:bluez_dbus_manager.cc(248)] Floss manager not present, cannot set Floss enabl
e/disable.
[main 2024-08-14T12:09:54.262Z] [File Watcher (node.js)] Request to start watching: /home/<user>/.config/VSCod
ium/User (excludes: <none>, includes: <all>, filter: <none>, correlationId: <none>),/home/<user>/.config/VSCod
ium/User/settings.json (excludes: <none>, includes: <all>, filter: <none>, correlationId: <none>)
libGL error: MESA-LOADER: failed to open radeonsi: /usr/lib/dri/radeonsi_dri.so: cannot open shared object fil
e: 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: radeonsi
libGL error: MESA-LOADER: failed to open swrast: /usr/lib/dri/swrast_dri.so: cannot open shared object file: N
o 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
[8582:0814/140954.271951:ERROR:angle_platform_impl.cc(44)] Display.cpp:1086 (initialize): ANGLE Display::initi
alize error 12289: Could not create a backing OpenGL context.
ERR: Display.cpp:1086 (initialize): ANGLE Display::initialize error 12289: Could not create a backing OpenGL c
ontext.
[8582:0814/140954.272012:ERROR:gl_display.cc(515)] EGL Driver message (Critical) eglInitialize: Could not crea
te a backing OpenGL context.
[8582:0814/140954.272018:ERROR:gl_display.cc(786)] eglInitialize OpenGL failed with error EGL_NOT_INITIALIZED,
trying next display type
[8582:0814/140954.272756:ERROR:angle_platform_impl.cc(44)] Display.cpp:1086 (initialize): ANGLE Display::initi
alize error 12289: Could not create a backing OpenGL context.
ERR: Display.cpp:1086 (initialize): ANGLE Display::initialize error 12289: Could not create a backing OpenGL c
ontext.
[8582:0814/140954.272775:ERROR:gl_display.cc(515)] EGL Driver message (Critical) eglInitialize: Could not crea
te a backing OpenGL context.
Gtk-Message: 14:09:54.130: Failed to load module "colorreload-gtk-module"
Gtk-Message: 14:09:54.130: Failed to load module "window-decorations-gtk-module"
[8555:0814/140954.176176:WARNING:bluez_dbus_manager.cc(248)] Floss manager not present, cannot set Floss enabl
e/disable.
[main 2024-08-14T12:09:54.262Z] [File Watcher (node.js)] Request to start watching: /home/<user>/.config
/VSCodium/User (excludes: <none>, includes: <all>, filter: <none>, correlationId: <none>),/home/<user>/.config
/VSCodium/User/settings.json (excludes: <none>, includes: <all>, filter: <none>, correlationId: <none>)
libGL error: MESA-LOADER: failed to open radeonsi: /usr/lib/dri/radeonsi_dri.so: cannot open shared object fil
e: 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: radeonsi
libGL error: MESA-LOADER: failed to open swrast: /usr/lib/dri/swrast_dri.so: cannot open shared object file: N
o 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
[8582:0814/140954.271951:ERROR:angle_platform_impl.cc(44)] Display.cpp:1086 (initialize): ANGLE Display::initi
alize error 12289: Could not create a backing OpenGL context.
ERR: Display.cpp:1086 (initialize): ANGLE Display::initialize error 12289: Could not create a backing OpenGL c
ontext.
[8582:0814/140954.272012:ERROR:gl_display.cc(515)] EGL Driver message (Critical) eglInitialize: Could not crea
te a backing OpenGL context.
[8582:0814/140954.272018:ERROR:gl_display.cc(786)] eglInitialize OpenGL failed with error EGL_NOT_INITIALIZED,
trying next display type
[8582:0814/140954.272756:ERROR:angle_platform_impl.cc(44)] Display.cpp:1086 (initialize): ANGLE Display::initi
alize error 12289: Could not create a backing OpenGL context.
ERR: Display.cpp:1086 (initialize): ANGLE Display::initialize error 12289: Could not create a backing OpenGL c
ontext.
[8582:0814/140954.272775:ERROR:gl_display.cc(515)] EGL Driver message (Critical) eglInitialize: Could not crea
te a backing OpenGL context.
...
I also did snap switch --edge codium and snap refresh, now on version 1.92.1.24225.
Also not crashing for me, at least on a quick test of a couple of hours using normally.
I also did a quick test switching display mode between laptop and/or external monitors. Seems normal.
I just checked that I'm on stable 1.93, I believe I have been using stable for quite a while, without any issues. I think this can be closed @daiyam, thanks!