Sway: Crash with Xwayland

[yujiri8]

• Sway Version: sway version 1.5-fd216b3a (Aug 27 2020, branch 'HEAD'). I also built wlroots from source at commit 330c50b.

• Debug Log: pastebin

• Configuration File: Default

• Description: Opened Sway, opened Alacritty, ran ps -e | grep Xway to ensure Xwayland was not already running, ran eog, Sway crashes.

I experience this crash on starting almost any X app. It doesn't hapen with Weston, so I'm fairly sure it's a problem with either Sway or wlroots.

This problem only appears with Xwayland. If I disable Xwayland in the config, I don't see any crashes (but then I can't run X apps). (eog, Fractal, and Firefox all support wayland in one way or another, but they seem to try to use X if they can, hence why eog can trigger the crash.)

It's also intermittent. eog and Fractal both work more often than not (and they never seem to fail once Xwayland is already running). Other X apps crash Sway consistently (Firefox can be made to use wayland with MOZ_ENABLE_WAYLAND which stops the crash). Occasionally, even just copy and paste triggers a crash, but that's rare enough that I haven't seen any kind of pattern to it.

[yujiri8]

Other things I should've mentioned:

OS: Artix Linux 5.8.3-artix1-1 #1 SMP PREEMPT
Arch: x86-64
Graphics hardware: Intel UHD Graphics 620

[emersion]

Please provide a stack trace. You can do so by compiling from source, reproducing the crash and then running coredumpctl gdb and then bt full.

Here are some instructions to compile from source: https://github.com/swaywm/sway/wiki/Development-Setup#compiling-as-a-subproject

[mschilli87]

@emersion: AFAIK coredumpctl is part of systemd and I would be surprised to find that on Artix as, to my understanding, it's basically Arch - systemd + OpenRC. Since I'm not running either of those (neither Arch, nor Artix, nor systemd), I could be wrong though. On my OpenRC-based Gentoo system at least, there is no coredumpctl. :wink:

[yujiri8]

I am not sure how to do the equivalent either since Sway doesn't seem to be leaving a core dump behind in the first place.

[mschilli87]

@yujiri8: Did you built Sway from source as pointed out by @emersion?

[yujiri8]

@mschilli87 My original build was from source, as indicated by the OP.

I remembered the alternative to coredumpctl was to use gdb when starting the program, but I cannot get Sway to start under gdb. It seems unable to open the display; it freezes my entire system if I run it from the TTY, and gdb prints messages about Sway's threads getting SIG33 if I try to run it from inside Weston.

I understand the importance of a stack trace, but I haven't managed to obtain one yet.

[mschilli87]

@yujiri8: I am not a expert on this but I think you could start sway normally and then trigger a dump using gcore <sway PID>.
Then, you could try gdb sway <dump file> to get the trace. I'm just not sure how usefull this would be as you want a stack trace at the time of the crash, not a random time while running sway.

[yujiri8]

Friends, I managed to get a stack trace!

Problem with GDB was that it kept halting on SIG33, which made it unresponsive. handle SIG33 nostop fixed that, so I was able to run Sway under GDB from inside Cinnamon. This might've affected the behavior a bit, since I couldn't reproduce the crash with eog and Fractal (they ran natively without starting XWayland), but with gimp I was able to reproduce the crash.

[yujiri8]

So a while before I posted here, I initially thought the problem was with XWayland instead and opened an issue there: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1062

Might have useful information, especially since someone else has just commented over there reporting a similar issue.

[yujiri8]

After rebuilding both Sway and Wlroots from source today, the issue seems to have been fixed by one of the commits this week. I suspect wlroots 3e03f786.

[Xyene]

Closing this issue since it appears to have been resolved. Feel free to reopen if you are still running into it.