electron: [Bug]: Electron crashes under Wayland
Preflight Checklist
- I have read the Contributing Guidelines for this project.
- I agree to follow the Code of Conduct that this project adheres to.
- I have searched the issue tracker for a bug report that matches the one I want to file, without success.
Electron Version
25.4.0
What operating system are you using?
Other Linux
Operating System Version
6.3.11
What arch are you using?
x64
Last Known Working Electron version
22
Expected Behavior
- Run
electron-fiddle --enable-features=UseOzonePlatform --ozone-platform=wayland. - Electron fiddle editor shows up.
Actual Behavior
Electron fiddle crashed after creating the main window.
Testcase Gist URL
No response
Additional Information
I’m using Sway as the compositor.
Attached is the gdb core dump file: core.zip
About this issue
- Original URL
- State: open
- Created a year ago
- Reactions: 76
- Comments: 28 (4 by maintainers)
This crash is the upstream issue of https://github.com/microsoft/vscode/issues/184124. If we look at the data there, >20 users have reported this electron crash. This implies possibly there are hundreds of unreported instances. Is there a chance this bug can be prioritized?
Can we get someone assigned to this? (@codebytere?)
Sorry for the delayed response and thanks for testing the builds, it is good to know that startup crash is avoided. Based on the traces from https://github.com/electron/electron/issues/39449#issuecomment-1793113439 there is one crash when rebuilding the menu and another crash when window title changes, both happens on opening new window. I will continue working on this issue next week, if someone else is interested in the mean time feel free to look into it.
I compiled electron-25.9.6 with
C*FLAGS=-O0 -gand got the stack trace of startup crash with value of variables:startup crash
With patch from @deepak1556, electron didn’t crash at startup or opening a new window, but when I closed one window, both crashed.
crash when close window
another process crashed
I got multiple crash coredumps, and it seems the invalid pointer of
ui::Layeris a constant value:0x0000000001010101I have struggled to reproduce this in a self-contained environment, but after spending a few minutes on it the other day, I somehow have ended up with something that causes
code --user-data-dir=$(mktemp -d)(VSCode 1.85.1, which uses Electron 25.9.7) to crash before it ever shows me a window, most of the time.It’s not perfect, but being able to do it with zero setup, repeatedly, means I can easily generate a dozen crashes in a row, whereas before, I only knew how to cause a crash with my own non-trivial
~/.config/Codedata dir. (Now I suspect the only problem with my existing VSCode state is that it has maximized windows, themselves the problem)While I could sometimes repro after spamming the “new window” keybind and mouse clicking (i.e. the double-click to maximize a window) for a while, KWin automation was way more effective. In
~/.config/kwinrulesrcI now have:And this is what it looks like in the UI (which is how I configured it, sadly I see no export/import):
With that in place, I was able to reproduce startup crashes in Electron 26 apps as well. I’m on NixOS, so that gave me a relatively easy (if perhaps ridiculous-looking) way to try that:
The
electronbinary from theelectron_26package itself crashed at least once, and both that and thepocket-cast-with-electron_26were able to cause some spooky crashes in other processes (ignoring the weird GPU interactions, it looks likekwin_waylandcrashed twice inQtWaylandServer::xdg_toplevel::handle_set_titlecallingKWin::Window::findWindowWithSameCaptionwhich then iterates over windows - maybe that one is just a bad Wayland window state that kwin doesn’t handle correctly, hard to tell really).One unmistakeable sign it was about to crash on startup, btw, was seeing the (minimized) window in more than one taskbar (I have per-monitor taskbars set to filter only to windows on that monitor, so the Electron window must be in a weird state for it to show up on multiple monitors’ taskbars like that).
However, repeating the same experiments with Electron 27 produced no crashes on startup (in line with e.g. https://github.com/electron/electron/issues/39449#issuecomment-1741330933). I’ve also tried VSCode Insiders (2023-12-20 build, which uses Electron 27.1.3), and I similarly couldn’t reproduce a startup crash, so if it still exists, it needs conditions I’m not accounting for (or is harder to hit).
Sadly, the exit/window close crashes are still there, but they’d be less disurptive to my VSCode experience than not being able to start it at all (without forcing XWayland and passing--disable-gpu).After more experimentation, VSCode Insiders doesn’t even crash when closing a window (with both
nativeandcustomtitlebars, even), there is a different crash when closing the whole app, not sure if related?And of course, since auto-maximizing works to reproduce the bug, what about the opposite? Yupp, I can finally start my (non-Insiders) VSCode again on Wayland, with GPU acceleration, perfect crisp per-monitor fractional scaling (like I’ve been waiting for, for months), and even close/open windows, with no crashes, “just” by setting the “Maximized horizontally/vertically” states to “Force” and “No”.
It’s definitely weird to use, you can’t even attempt to maximize or edge-snap the windows, they feel very “floaty”. Fullscreening still seems to work though, so that’s a nice potential workaround.
My only regret is that I hadn’t picked up on the maximization connection sooner, and tried harder to repro the crash with a fresh
--user-data-dir(instead of going with XWayland +--disable-gpufor months).EDIT: the workaround also appears to fix Obsidian (the other app I use, still stuck on Electron 25).
I have been looking into this issue recently and was able to repro one of the crash scenarios with pointer focus into the application, debugging showed that an invalid layer is being passed into
ui::Layer::ConvertPointToLayer. I haven’t confirmed yet whyWebContentsViewAurabecomes detached but added the following workaroundwhich seems to address the crash on startup for VS Code and electron-fiddle. I verified this using
sway version 1.8.1-68d620a8 (Sep 28 2023, branch 'HEAD'). Can affected users also test the following build with electron-fiddle and confirm if it addresses the crashes.For visibility: On the downstream & other issues (microsoft/vscode#184124, electron/electron#37531) you can find stacktraces with debug symbols. All signs seem to point towards a race condition type of issue during startup & menu build.
Some example stacktraces (thanks to
coredumpctl+gdb):ERROR:elf_dynamic_array_reader.h(64)] tag not found#0 0x0000562d9cd48f77 _ZN5views12_GLOBAL__N_120BuildViewsWithLayersEPNS_4ViewEPSt6vectorIS2_SaIS2_EE (electron + 0x8da0f77)views::(anonymous namespace)::BuildViewsWithLayers(views::View*, std::vector<views::View*, std::allocator<views::View*> >*) ()ERROR:elf_dynamic_array_reader.h(64)] tag not found#0 0x000055c8c9767d69 _ZN5views4View22UpdateChildLayerBoundsERKNS0_15LayerOffsetDataE (electron + 0x8d83d69)views::View::UpdateChildLayerBounds(views::View::LayerOffsetData const&) ()Reproduction case is pretty easy: Simply install & try to start VSCode on ArchLinux + Wayland desktop environment (e.g. Sway), Manjaro Sway edition, or other Arch-based distros with Wayland-based desktop environment (e.g. EndeavourOS, Garuda Linux, etc…).
I reproduced on Manjaro Sway Edition:
Note: Manjaro does not yet ship
debuginfoddebug symbols forcode, norelectron25, so these must be built manually. You may have better out-of-the-box support fordebuginfoddebug symbols on “vanilla” Arch Linux. Although, first-time installation of ArchLinux in general requires a bit of *nix knowledge & time. The crash should be easily reproducible on Wayland + Sway, and probably other similar desktop environments (e.g. Hyprland, River, Wayfire, etc…)+1 to this! Many appear to be affected. Please & Thank You 🙏
@3liasP Can you open multiple windows without a crash with this work-around? For me this only works for the first window.
In older versions I could retry 3-10 times until multiple windows open successful, now all attempts lead to a crash.
@3liasP: Hope it helps! You might try checking whether other Xwayland applications are blurry also. There are some reports of other IDEs including JetBrains being blurry under XWayland
I’m seeing the same behavior on my end as well with Wayland and was able to reproduce it with electron-fiddle with the same arguments as @tengyifei - In my case the window show up, but crashes when I maximize it. It works fine when not run under Wayland.
System details:
Looks like this is affecting other Electron users on Wayland not just VSCode: Signal: https://github.com/signalapp/Signal-Desktop/issues/6247 Element Matrix Client: https://github.com/vector-im/element-desktop/issues/1026
This also seems to have some history with 22.x as well: https://github.com/electron/electron/issues/37531