hardware: eeepc 1005pe (old netbook with N450/GMA3150 GL 1.4)
linux void musl
sway 1.4
default config file with just some additional key bindgings
no systemd
crash happens often but not always, in this log the first reload was successful
perhaps related: when first starting sway some garbage is displayed on the swaybar (almost like uninitialized memory) for a fraction of a second, happens always
log:
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
I coincidentally had this happen to me just now while running swaymsg reload in a terminal (as a workaround for https://github.com/swaywm/sway/issues/5029, which reliably crashes reload by keybinding). I've uploaded the log here. It's not at all reproducible as frequently as https://github.com/swaywm/sway/issues/5029, and only happened after ~2 days of uptime. (It might also very well be a different issue from OP's.)
I experienced this several times on sway 1.4, and just now again using a master build built from 3078f232581d1dcd548810370c193c6d235d2e82. Here is the stack trace from the master build:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007fdc836051e5 in __strlen_avx2 () from /usr/lib/libc.so.6
[Current thread is 1 (Thread 0x7fdc827d7dc0 (LWP 20354))]
(gdb) bt
#0 0x00007fdc836051e5 in __strlen_avx2 () at /usr/lib/libc.so.6
#1 0x00007fdc83510676 in __vfprintf_internal () at /usr/lib/libc.so.6
#2 0x00007fdc835115e6 in buffered_vfprintf () at /usr/lib/libc.so.6
#3 0x00007fdc8350e774 in __vfprintf_internal () at /usr/lib/libc.so.6
#4 0x0000562167f4ee6a in sway_log_stderr
(verbosity=SWAY_DEBUG, fmt=0x562167f58ef0 "[%s:%d] running command for binding: %s", args=0x7ffc1df10ae0) at ../common/log.c:89
#5 0x0000562167f4efee in _sway_log (verbosity=SWAY_DEBUG, fmt=0x562167f58ef0 "[%s:%d] running command for binding: %s")
at ../common/log.c:115
#6 0x0000562167f25cce in seat_execute_command (seat=0x562169f7e740, binding=0x56216a2aa2f0) at ../sway/commands/bind.c:615
#7 0x0000562167f124ac in handle_keyboard_repeat (data=0x56216a4bf9e0) at ../sway/input/keyboard.c:509
#8 0x00007fdc836f01dd in wl_event_loop_dispatch () at /usr/lib/libwayland-server.so.0
#9 0x00007fdc836ee4e7 in wl_display_run () at /usr/lib/libwayland-server.so.0
#10 0x0000562167f00781 in server_run (server=0x562167f71200 <server>) at ../sway/server.c:218
#11 0x0000562167effd1c in main (argc=2, argv=0x7ffc1df10fe8) at ../sway/main.c:409
I did some reversing of the unsymbolicated 1.4 binary I previously saw the issue on (after I was unable to immediately reproduce it on master), and the stack trace there was more or less the same.
I can provide a core dump and associated binary (with full debugging symbols) privately if you need it.
Edit: my issue seems to be #5029, which I hadn't noticed @Xyene mentioned. Their trace is different than mine, so maybe this issue should be used to track that one. I don't know which of the bugs @LamaRaz was hitting.
sway version: sway version 1.4-7c37e9d0 (May 8 2020, branch 'master')
Arch linux, mesa 20.0.6-2 with the iris intel driver.
I have the exact same issue. I can reproduce this consistently on a clean sway config by doing $mod+shift+c to reload sway endlessly. The faster you press it, the more likely you are to get it to crash.
Interestingly enough, the crash is different depending on how sway is run.
First, with WAYLAND_DEBUG=1 sway -c /etc/sway/config -d 2>sway.log:
debug log: https://0x0.st/i_aA.log
backtrace: https://0x0.st/i_am.txt
Then, with no debugging WAYLAND_DEBUG=1 sway -c /etc/sway/config 2>sway_no_debug.log:
debug log: https://0x0.st/i_aa.log
backtrace: https://0x0.st/i_aB.txt
As you can see, the common path is through handle_keyboard_repeat() and seat_execute_command(), but diverges afterwards. Some sort of string corruption or something I'm guessing? Definitely seems related to #5029.
@LaserEyess that looks like the same issue as #5029, you can try the patch from https://github.com/swaywm/sway/pull/5317 that fixes that.
Most helpful comment
I experienced this several times on sway 1.4, and just now again using a master build built from 3078f232581d1dcd548810370c193c6d235d2e82. Here is the stack trace from the master build:
I did some reversing of the unsymbolicated 1.4 binary I previously saw the issue on (after I was unable to immediately reproduce it on master), and the stack trace there was more or less the same.
I can provide a core dump and associated binary (with full debugging symbols) privately if you need it.
Edit: my issue seems to be #5029, which I hadn't noticed @Xyene mentioned. Their trace is different than mine, so maybe this issue should be used to track that one. I don't know which of the bugs @LamaRaz was hitting.