search

VSCodium / vscodium

binary releases of VS Code without MS branding/telemetry/licensing
https://vscodium.com
MIT License
25.04k stars 1.07k forks source link

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

Open geekley opened 3 months ago

geekley commented 3 months ago

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

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 commented 3 months ago

Ok, I've reverted the snap the 1.89.1.24130.

daiyam commented 3 months ago

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

You can do codium --verbose

geekley commented 3 months ago

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 commented 3 months ago

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

daiyam commented 3 months ago

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 commented 3 months ago

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.

daiyam commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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

geekley commented 3 months ago

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.

shelvesdragon commented 3 months ago

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:

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-gpu does not crash, but the window often freezes, so that I have to bring it down manually and restart
geekley commented 3 months ago

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.

daiyam commented 3 months ago

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.

shelvesdragon commented 3 months ago

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

daiyam commented 3 months ago

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

shelvesdragon commented 3 months ago

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?

daiyam commented 2 months ago

The 1.91.x are available on the edge channel. Can you tell me if it's working? Thx

shelvesdragon commented 2 months ago

tl;dr:

daiyam commented 2 months ago

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.

daiyam commented 1 month ago

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...)

shelvesdragon commented 1 month ago

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.
...
geekley commented 1 month ago

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.

daiyam commented 3 weeks ago

I've pushed the 1.93 to stable.