electron: [Bug]: Crash when opened under Wayland
Electron Version
22.0.3
What operating system are you using?
Other Linux
Operating System Version
6.2.2-arch1-1
What arch are you using?
x64
Last Known Working Electron version
?
Expected Behavior
start without crashing
Actual Behavior
/home/john/.config/Element exists: yes
/home/john/.config/Riot exists: no
No update_base_url is defined: auto update is disabled
Fetching translation json for locale: en_EN
Changing application language to en-us
Fetching translation json for locale: en-us
Resetting the UI components after locale change
Resetting the UI components after locale change
[2710:0308/104609.256916:ERROR:gpu_init.cc(523)] Passthrough is not supported, GL is egl, ANGLE is
fish: Job 1, 'element-desktop' terminated by signal SIGSEGV (Address boundary error)
Testcase Gist URL
No response
Additional Information
This is happening since I have added
--enable-features=WaylandWindowDecorations
--ozone-platform-hint=auto
to ~/.config/electron-flags.conf.
I am using sway on wayland.
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 26
- Comments: 25 (3 by maintainers)
So I have a similiar issue, it’s just that Electron v25.3.2 works half of the time… Launched from Hyprland (git version)
Log
Using this command to launch electron itself…
electron --enable-features=UseOzonePlatform --ozone-platform=wayland --ozone-platform-hint=autogives me this on a crash (also it hangs the terminal/doesnt give control back without Ctrl+C)
Same output is given whenever it successfully launches and it hangs at the same spot! It seems like for me, electron thinks it has launched while it didn’t…
PS:
--verbosedoesn’t do anything hereI’ve tested Tutanota and Element flatpak which both have updated to Electron 26 and the crashes are gone entirely. 😃
Reproduced on Arch Linux using the distribution packaged vscode and electron22 with debug symbols installed. Got a debugger with
The issue seems to happen about 1/2 of the time with electron occasionally managing to start multiple times in a row and then fail many times. So the behavior doesn’t seem to be truly random.
The debugger yielded following stacktraces for the segfaults:
1: In printing::PrinterSemanticCapsAndDefaults::Paper::Paper
2: In ui::WaylandZcrColorManagementSurface::SetColorSpace
3: In printing::PrinterSemanticCapsAndDefaults::Paper::Paper (Interestingly the window managed to open & display code editor with file open already)
4: In views::(anonymous namespace)::BuildViewsWithLayers
5: In views::View::UpdateChildLayerBounds (as in others, window visible and has dark grey side bar and lighter color in other window visible already, no content showing though)
It seems that I can somewhat reliably reproduce the issue by changing the display I’m focused on compared to last execution. Not sure about changing monitor in focus midst the app is launching though. Interestingly sometimes the application crashes continuously when tried to launch on some display consecutively, in those cases trying to launch is on other monitor seems to most often help and get it running.
So the crashloops are (1.) starting consecutively on same display crashing after window creation, launching on another screen helps, and (2.) starting on alternating displays, restarting using same display may help.
I couldn’t reproduce the issue with Electron demo app which is launched when removing the
/usr/lib/code/code.jsfrom execution arguments so this seems to be an issue with how the application interacts with Electron.Using Sway 1.8.1 as Wayland compositor and 2 monitors with 3440x1440 (scale 1) and 3840x2160 (scale 1.7) resolutions. Changing both scalings to be just 1 didn’t help with the crashes.
Seems there are possibly multiple codepaths & crashes with vscode +
electron22on Wayland. Nothing fancy on my system… it’s a pretty fresh install of stock Manjaro Sway edition with single display & the integrated GPU that’s built-in to the motherboard chipset.I was able to get stacktraces for one of these in the downstream bug report here: microsoft/vscode#184124. In that case it was in:
See downstream bug comment for details on that one.
Just now I was able to roll the dice again by restarting
codevia cmdline & reproduced @Jaakkonen’s case number 5: inviews::View::UpdateChildLayerBounds(views::View::LayerOffsetData const&) ()For that one, see below:
EXPAND for platform / package version info
Intel HD Graphics 630driver:i915v: kernel4.6Mesa23.0.2renderer:Mesa Intel HD Graphics 630(KBLHere are logs from
code --verbose:EXPAND terminal log
EXPAND for stacktraces via
coredumpctl gdb 2754875 .... btEXPAND for CPU registers via
(gdb) info all-registersAs @travier said it’s related to window being maximized. On sway with Element flatpak I had to follow this comment and it works perfectly. And when I try to make the window not floating by clicking
shift+mod+spaceit crashes immediately.EDIT: Looks like another electron app Signal has the same problem https://github.com/signalapp/Signal-Desktop/issues/6247
I’m also experiencing the same issue on a machine with two monitors (high-ish DPI, but scale = 1). With debuginfod, I got the following stacktrace, it’s different from @hrdl-github’s but also has the same memcpy called from
StoragePartitionConfig’s copy constructor at the top:I couldn’t reproduce with a different electron app than Element because they all crash or immediately stop for seemingly unrelated reasons 🥲 (e.g. Signal Desktop for some reason trying to do some migration on its DB before starting the main window when run through the regular electron binary)
… but VSCode has also been crashing at startup for me when the ozone wayland backend is enabled.
@VerteDinde with two stack traces, is it still right for this to be marked as need-info?
Running
/usr/lib/electron/electron --disable-dev-mode --ozone-platform=wayland /usr/lib/element/app.asar(element-desktop 1.11.20-1 from the Arch Linux community repository) reliably gives me the following:stack trace
This does not happen without the
--ozone-platform=waylandoption. Sincesignal-desktopupdated to element 22 I’ve been experiencing frequent crashes, especially at startup when no TTY is attached. I do not have a good stack trace though. Also relevant: https://github.com/signalapp/Signal-Desktop/issues/6247 and https://github.com/signalapp/Signal-Desktop/issues/6260Closing as fixed as per previous two comments. @threema-danilo, @RubberDuckShobe, thanks for the info!
In our application, this issue seems fixed starting with Electron 28. (Version 27 still had some rendering issues, and sometimes segfaults when exiting. I did not observe this yet with 28.)
I filed a similar issue in vector-im/element-desktop#873 which only occurs under certain circumstances (mixed-scaled dual monitor setup). Note that it behaves a bit differently in element-nightly (electron 24.0.0) and element 1.11.29 (electron 23.1.3).
This might be related. (Or not.)
This might be a Chromium issue. I encounter similar issues with Chrome, Brave on Arch for a couple weeks at this point, and found this when I was searching for the error.
I also use Wayland/Sway/Arch, with multiple monitors in different scales.