[SOLVED] Some electron apps segfaulting on one Arch install but not...

avr · 2026-04-15 17:52:09

I have two different computers that have Arch Linux installed: a 2011 MBP and a "modern" desktop. Both are kept up to date with pacman -Syyu. This post concerns the MBP.

I'm noticing that some electron apps such as 1Password (AUR), Signal, and Obsidian segfault every time I try to use them. Other electron apps like Discord work just fine. I'm also noticing some general slowness recently (I hate to post really vague stuff like that because I haven't been able to quantify it, but how it manifests is occasionally slow pacman -Syyu startup, some input delay in the terminal emulator (Kitty), and a lot of slowness around coredumpctl even listing coredumps is slow and it warns that coredumpctl.system is still running). I already checked the normal things like network speed and SSD health and everything seems fine. Bootup is fine with both the LTS kernel and the latest Arch-supported kernel.

Both stack traces are the same, and I can only access the top frame

⚠️ warning: failed to parse execution context from corefile: Cannot access memory at address 0x7ffdff1aefd8
❌️ Failed to read a valid object file image from memory.
Core was generated by `/usr/lib/electron39/electron /usr/lib/obsidian/app.asar'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000055e7ffd0140e in uv.loop_interrupt ()
[Current thread is 1 (LWP 4731)]
(gdb) bt
#0  0x000055e7ffd0140e in uv.loop_interrupt ()
Backtrace stopped: Cannot access memory at address 0x7ffdff1abb28

I'm not sure if the general "slowness" is related to the constant segfaulting with the electron apps. No other apps are segfaulting at the moment. I also am reasonably accustomed to the speed to expect on modern Linux running on this older hardware as I've been using this MBP with Arch for over 2 years, so at the moment this does feel like a performance degradation. CPU usage and memory usage remains constant under 40% across all cores even during the slow operations. No fan turning on, no swap is being used either, sensors are normal.

Does anyone know if these issues are related, and / or how to resolve the issue with the Electron apps?

6.18.22-1-lts

xfce4-panel 4.20.7-1
xorg-server 21.1.22-1
pacman 7.1.0.r9.g54d9411-1
obsidian 1.12.7-1
1password 8.12.8-26
signal-desktop 8.6.1-1
glibc 2.43+r5+g856c426a7534-1
kitty 0.46.2-1
systemd 260.1-1

Last edited by avr (2026-04-15 23:32:28)

seth · 2026-04-15 20:06:08

pacman -Syyu

"man pacman", see what the second "y" does, understand why you don't want that and the stop doing this unless you really. REALLY. mean to.

On topic: session is xfce on X11? (If not, what else?)
Please post your Xorg log, https://wiki.archlinux.org/title/Xorg#General and the output of

glxinfo -B

Both stack traces are the same, and I can only access the top frame

Do signal/1password also run through electron 39??
Does it help to run them w/ "--disable-gpu" ?
(Looking there mostly because of the overall slowness being our best lead atm)

avr · 2026-04-15 21:06:10

I'll switch to using `pacman -Syu` instead, thank you and apologies about excessive refreshes. Yes, I've tried --disable-gpu on the electron apps and they still segfault after taking a while to load. I have no idea what electron version 1Password uses and I'm not sure how to inspect that (it also doesn't create a coredump).

Obsidian with GPU disabled

xdg-settings: default-url-scheme-handler not implemented for xfce
2026-04-15 20:46:00 Loaded main app package /usr/lib/obsidian/obsidian.asar
[2]    16104 segmentation fault (core dumped)  obsidian --disable-gpu
obsidian --disable-gpu  0.41s user 34.41s system 17% cpu 3:21.05 total

[    26.721] (--) Log file renamed from "/home/avr/.local/share/xorg/Xorg.pid-2102.log" to "/home/avr/.local/share/xorg/Xorg.0.log"
[    26.733] (==) Log file: "/home/avr/.local/share/xorg/Xorg.0.log", Time: Wed Apr 15 10:26:50 2026

If I tail the xorg logs while trying to run one of the electron apps w/o the GPU I don't get any new messages.

For timing signal w/o the GPU, I noticed that it quickly reports a failure due to no Wayland but the process still hangs for about the same amount of time and still segfaults. I also noticed that Chromium hits a similar failure whereas this had been working on XFCE up until about last week.

NODE_ENV production
NODE_CONFIG_DIR /usr/lib/signal-desktop/resources/app.asar/config
NODE_CONFIG {}
ALLOW_CONFIG_MUTATIONS undefined
HOSTNAME *****
NODE_APP_INSTANCE undefined
SUPPRESS_NO_CONFIG_WARNING undefined
SIGNAL_ENABLE_HTTP undefined
userData: /home/avr/.config/Signal
[17224:0415/135457.045235:ERROR:ui/ozone/platform/wayland/host/wayland_connection.cc:202] Failed to connect to Wayland display: No such file or directory (2)
[17224:0415/135457.048263:ERROR:ui/ozone/platform/wayland/ozone_platform_wayland.cc:282] Failed to initialize Wayland platform
[17224:0415/135457.048315:ERROR:ui/aura/env.cc:257] The platform failed to initialize.  Exiting.
[2]    17224 segmentation fault (core dumped)  signal-desktop --disable-gpu
signal-desktop --disable-gpu  1.17s user 35.64s system 17% cpu 3:31.56 total

[17736:17736:0415/140228.681977:ERROR:ui/ozone/platform/wayland/host/wayland_connection.cc:202] Failed to connect to Wayland display: No such file or directory (2)
[17736:17736:0415/140228.682033:ERROR:ui/ozone/platform/wayland/ozone_platform_wayland.cc:281] Failed to initialize Wayland platform
[17736:17736:0415/140228.682063:ERROR:ui/aura/env.cc:246] The platform failed to initialize.  Exiting.
chromium  0.09s user 0.04s system 72% cpu 0.181 total

name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel (0x8086)
    Device: Mesa Intel(R) HD Graphics 3000 (SNB GT2) (0x126)
    Version: 26.0.4
    Accelerated: yes
    Video memory: 1536MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 3.3
    Max compat profile version: 3.3
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) HD Graphics 3000 (SNB GT2)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 26.0.4-arch1.1
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.3 (Compatibility Profile) Mesa 26.0.4-arch1.1
OpenGL shading language version string: 3.30
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile

OpenGL ES profile version string: OpenGL ES 3.0 Mesa 26.0.4-arch1.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00

seth · 2026-04-15 21:43:32

If I tail the xorg logs while trying to run one of the electron apps w/o the GPU I don't get any new messages.

I wanted to see the logs for an overall idea about the server situation.

Device: Mesa Intel(R) HD Graphics 3000 (SNB GT2) (0x126)

xf86-video-intel + mesa-amber?

For timing signal w/o the GPU, I noticed that it quickly reports a failure due to no Wayland

Are you using GDM?
https://bbs.archlinux.org/viewtopic.php?id=313015

avr · 2026-04-15 21:58:43

Yes I have gdm.service running in systemd. I'm open to switching to another display manager as long as I can use something relatively low spec for this old laptop. I'm not using either xf86-video-intel or mesa-amber. The only Intel graphics related packages I have are

lib32-vulkan-intel 1:26.0.4-1
libva-intel-driver 2.4.1-6
linux-firmware-intel 20260309-1
vulkan-intel 1:26.0.4-1

here's the entire xorg log

seth · 2026-04-15 22:02:46

Try eg. lightdm - GDM 50 can no longer start X11 sessions (this is a bug because it claims differently but that bug is also known since a year and what sparked the code reversal in 49…)
Technically you don't need any DM on a de facto single-user system but can just xinit/startx/startxfce4 into a locked session.

avr · 2026-04-15 23:31:57

Lightdm completely fixed the issue, all of those Electron apps plus Chromium now work. Have yet to experience any slowness. Thank you.

mir · 2026-04-17 09:17:24

This had bitten me yesterday, too, with chromium not working.

My last update was 2026-02-26, when gdm updated to 49.2-1, so this is probably related to gdm 50.0. The bug might be known for a year if you follow this issue, for others it's a recent change that unexpectedly breaks their system.

Shouldn't this be communicated more broadly, like on the latest news at archlinux.org?

seth · 2026-04-17 12:33:05

https://gitlab.gnome.org/GNOME/gdm/-/issues/1063

Gnome/GDM was supposed to remove the relevnat code for v49 but figured that this causes this problem, reverted the withdrawal and scheduled it for v50 but then apparently just plowed through w/o any further concern.

Shouldn't this be communicated more broadly, like on the latest news at archlinux.org?

PSA: every major gnome update will severely break random shit. It's always been like this

Arch Linux

#1 2026-04-15 17:52:09

[SOLVED] Some electron apps segfaulting on one Arch install but not...

#2 2026-04-15 20:06:08

Re: [SOLVED] Some electron apps segfaulting on one Arch install but not...

#3 2026-04-15 21:06:10

Re: [SOLVED] Some electron apps segfaulting on one Arch install but not...

#4 2026-04-15 21:43:32

Re: [SOLVED] Some electron apps segfaulting on one Arch install but not...

#5 2026-04-15 21:58:43

Re: [SOLVED] Some electron apps segfaulting on one Arch install but not...

#6 2026-04-15 22:02:46

Re: [SOLVED] Some electron apps segfaulting on one Arch install but not...

#7 2026-04-15 23:31:57

Re: [SOLVED] Some electron apps segfaulting on one Arch install but not...

#8 2026-04-17 09:17:24

Re: [SOLVED] Some electron apps segfaulting on one Arch install but not...

#9 2026-04-17 12:33:05

Re: [SOLVED] Some electron apps segfaulting on one Arch install but not...

Board footer