Alacritty is crashing rarely, but randomly

[ericonr]

System

• xuname:
  Void 5.8.3_1 x86_64-musl GenuineIntel notuptodate rrnDDFFFFFFFFFFFFFFFFFFFFFFFFFFFF
• package:
  alacritty-0.5.0_1

Expected behavior

It will stay open indefinitely.

Actual behavior

It crashes randomly, usually when I'm away from the device. I come back and the workspace occupied by alacritty is now empty. I managed to grab a core file and it doesn't have too much info, but notes that there was a SIGILL that killed the process.

dmesg:

[499358.471354] traps: alacritty[3578] trap invalid opcode ip:55f400fb15de sp:7ffff9af63b0 error:0 in alacritty[55f400c9d000+3d5000]

Interestingly enough, another alacritty instance just disappeared, without leaving complaints in dmesg or a core file. This is usually what happens.

Steps to reproduce the behavior

• run alacritty in sway
• use i915 driver, if that matters
• use fish terminal, if that matters

I'm opening this issue here first because we do patch stuff around the relevant toolchains, but I will also look into upstream.

[ericonr]

New dmesg: [756383.268185] traps: alacritty[10149] trap invalid opcode ip:5620875805de sp:7fff38656930 error:0 in alacritty[56208726c000+3d5000]

[ghost]

Perhaps related, I have had this issue and an even more egregious variant where entire applications launched from alacritty would disappear.

On Fedora 31 Gnome Wayland. Optimus laptop with zram constantly being utilized. Discrete GPU was turned off in bios at the time.

Solution was to turn on the discrete GPU and use Nouveau. I suspect that for whatever reason the Intel GPU <-> system memory interaction was handled more poorly than with Nouveau somehow mediating it. The switch solved other graphical problems when memory was being full too (stuttering sound in videos + kernel cpu utilization through the roof), which ironically was what I wanted to avoid by turning off the discrete GPU to begin with.
As far as I can tell the dGPU is never even used (optimus power button light indicator), yet the problem is solved.

Alacritty uses gpu api (I recall being unable to even run it on some very old hardware because of opengl version or something) which probably makes it subject to GPU memory constraints in some way.

[svenper]

I have had no problems like this with alacritty on bspwm, on a computer with only Intel internal graphics.

[fosslinux]

I do not have this issue on i915 alacritty on GNOME Xorg no dGPU, or on nvidia340/noveadu alacritty on i3. I am using glibc on both systesms.

@ericonr @svenper @tarkov2213 Do you use musl? This opcode stuff looks muslish.

[ericonr]

Yeah, Musl. Do you think it could be blowing past the per thread stack, perhaps?

[ghost]

The Fedora system I had this exact issue happen to wasn't musl. But I found a fix, zram with vm.watermark_scale_factor=800
Never happened again. Might be an issue with some graphics API usage and how it handles low vram situations?

[ericonr]

There isn't really anything to act on, and I haven't experienced it for some time.

@tarkov2213 interestingly I have also recently enabled zram