swaylock
swaylock copied to clipboard
Published
20 hours ago •
swaywm
swaywm
Swaylock crashes after returning from hybernation
I use sway with swaylock on Arch Linux.
sway version 1.5.1 swaylock version 1.4
During use, I close the laptop lid and the laptop goes into sleep and later into hybernation. After opening the lid, the laptop boots (via grub2) and returns to the swaylock state. So I have to provide my fingerprint (to the fingerprint reader) and swaylock provided access to sway.
However, the last few times swaylock (or sway?) crashed after the boot. The user then drops into the TTY without asking credentials. From there the user can restart sway again.
The crash is bad enough, but dropping to the TTY without providing credentials is a real problem.
I would like to help in providing a more detailed bugreport, but I am not sure how to do this. Please let me know if and what other information you need (and how I can obtain that information).
I am not sure if it is useful, but this is the TTY I get dropped into after the crash (there are some error messages).
Please provide a stack trace. You can do so by running coredumpctl gdb and then bt full. In particular the core for sway is the interesting one, since this is a compositor crash rather than a swaylock crash.
Xyene, when do I perform this stack trace? Right after the next crash? Or at any time after a crash?
I just installed gdb and executed those commands, and then it shows the following:
λ ~/ coredumpctl gdb
PID: 4241 (firewall-applet)
UID: 1000 (patrick)
GID: 1000 (patrick)
Signal: 6 (ABRT)
Timestamp: Tue 2021-02-02 20:18:56 CET (1h 51min ago)
Command Line: /usr/bin/python /usr/bin/firewall-applet
Executable: /usr/bin/python3.9
Control Group: /user.slice/user-1000.slice/session-1.scope
Unit: session-1.scope
Slice: user-1000.slice
Session: 1
Owner UID: 1000 (patrick)
Boot ID: b56011be5e464f7d81d84de908e8eadc
Machine ID: 9750f21e4965473682827a1680010c18
Hostname: plato
Storage: /var/lib/systemd/coredump/core.firewall-applet.1000.b56011be5e464f7d81d84de908e8eadc.4241.1612293536000000.zst
Message: Process 4241 (firewall-applet) of user 1000 dumped core.
[REMOVED BECAUSE IT WAS NOT USEFULL AND JUST CLUTTER]
That's not the right app (looks like firewall-applet cored when the compositor went down).
If you do coredumpctl list you should see all (recent-ish) cores, including some from sway. You can pass the sway as a parameter like coredumpctl gdb sway to see the latest core, or coredumpctl gdb [some pid from list] if the latest core is not interesting.
This is the sway stacktrace:
λ ~/ coredumpctl gdb sway
PID: 969 (sway)
UID: 1000 (patrick)
GID: 1000 (patrick)
Signal: 11 (SEGV)
Timestamp: Tue 2021-02-02 13:34:51 CET (21h ago)
Command Line: sway
Executable: /usr/bin/sway
Control Group: /user.slice/user-1000.slice/session-1.scope
Unit: session-1.scope
Slice: user-1000.slice
Session: 1
Owner UID: 1000 (patrick)
Boot ID: b56011be5e464f7d81d84de908e8eadc
Machine ID: 9750f21e4965473682827a1680010c18
Hostname: plato
Storage: /var/lib/systemd/coredump/core.sway.1000.b56011be5e464f7d81d84de908e8eadc.969.1612269291000000.zst
Message: Process 969 (sway) of user 1000 dumped core.
Stack trace of thread 969:
#0 0x000055775cf57056 n/a (sway + 0xf056)
#1 0x00007f0360cc370e n/a (libwlroots.so.7 + 0x6e70e)
#2 0x00007f03603ffacd n/a (libffi.so.7 + 0x6acd)
#3 0x00007f03603ff03a n/a (libffi.so.7 + 0x603a)
#4 0x00007f0360d10124 n/a (libwayland-server.so.0 + 0xd124)
#5 0x00007f0360d0b57c n/a (libwayland-server.so.0 + 0x857c)
#6 0x00007f0360d0e07a wl_event_loop_dispatch (libwayland-server.so.0 + 0xb07a)
#7 0x00007f0360d0bbe7 wl_display_run (libwayland-server.so.0 + 0x8be7)
#8 0x000055775cf5882f n/a (sway + 0x1082f)
#9 0x00007f0360a34152 __libc_start_main (libc.so.6 + 0x28152)
#10 0x000055775cf58bae n/a (sway + 0x10bae)
Stack trace of thread 979:
#0 0x00007f03609f96a2 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf6a2)
#1 0x00007f035eabeb3c n/a (radeonsi_dri.so + 0x4edb3c)
#2 0x00007f035eabd308 n/a (radeonsi_dri.so + 0x4ec308)
#3 0x00007f03609f33e9 start_thread (libpthread.so.0 + 0x93e9)
#4 0x00007f0360b0c293 __clone (libc.so.6 + 0x100293)
Stack trace of thread 977:
#0 0x00007f03609f96a2 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf6a2)
#1 0x00007f035eabeb3c n/a (radeonsi_dri.so + 0x4edb3c)
#2 0x00007f035eabd308 n/a (radeonsi_dri.so + 0x4ec308)
#3 0x00007f03609f33e9 start_thread (libpthread.so.0 + 0x93e9)
#4 0x00007f0360b0c293 __clone (libc.so.6 + 0x100293)
Stack trace of thread 976:
#0 0x00007f03609f96a2 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf6a2)
#1 0x00007f035eabeb3c n/a (radeonsi_dri.so + 0x4edb3c)
#2 0x00007f035eabd308 n/a (radeonsi_dri.so + 0x4ec308)
#3 0x00007f03609f33e9 start_thread (libpthread.so.0 + 0x93e9)
#4 0x00007f0360b0c293 __clone (libc.so.6 + 0x100293)
Stack trace of thread 974:
#0 0x00007f03609f96a2 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf6a2)
#1 0x00007f035eabeb3c n/a (radeonsi_dri.so + 0x4edb3c)
#2 0x00007f035eabd308 n/a (radeonsi_dri.so + 0x4ec308)
#3 0x00007f03609f33e9 start_thread (libpthread.so.0 + 0x93e9)
#4 0x00007f0360b0c293 __clone (libc.so.6 + 0x100293)
Stack trace of thread 971:
#0 0x00007f03609f96a2 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf6a2)
#1 0x00007f035eabeb3c n/a (radeonsi_dri.so + 0x4edb3c)
#2 0x00007f035eabd308 n/a (radeonsi_dri.so + 0x4ec308)
#3 0x00007f03609f33e9 start_thread (libpthread.so.0 + 0x93e9)
#4 0x00007f0360b0c293 __clone (libc.so.6 + 0x100293)
Stack trace of thread 972:
#0 0x00007f03609f96a2 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf6a2)
#1 0x00007f035eabeb3c n/a (radeonsi_dri.so + 0x4edb3c)
#2 0x00007f035eabd308 n/a (radeonsi_dri.so + 0x4ec308)
#3 0x00007f03609f33e9 start_thread (libpthread.so.0 + 0x93e9)
#4 0x00007f0360b0c293 __clone (libc.so.6 + 0x100293)
Stack trace of thread 978:
#0 0x00007f03609f96a2 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf6a2)
#1 0x00007f035eabeb3c n/a (radeonsi_dri.so + 0x4edb3c)
#2 0x00007f035eabd308 n/a (radeonsi_dri.so + 0x4ec308)
#3 0x00007f03609f33e9 start_thread (libpthread.so.0 + 0x93e9)
#4 0x00007f0360b0c293 __clone (libc.so.6 + 0x100293)
Stack trace of thread 984:
#0 0x00007f03609f96a2 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf6a2)
#1 0x00007f035eabeb3c n/a (radeonsi_dri.so + 0x4edb3c)
#2 0x00007f035eabd308 n/a (radeonsi_dri.so + 0x4ec308)
#3 0x00007f03609f33e9 start_thread (libpthread.so.0 + 0x93e9)
#4 0x00007f0360b0c293 __clone (libc.so.6 + 0x100293)
Stack trace of thread 982:
#0 0x00007f03609f96a2 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf6a2)
#1 0x00007f035eabeb3c n/a (radeonsi_dri.so + 0x4edb3c)
#2 0x00007f035eabd308 n/a (radeonsi_dri.so + 0x4ec308)
#3 0x00007f03609f33e9 start_thread (libpthread.so.0 + 0x93e9)
#4 0x00007f0360b0c293 __clone (libc.so.6 + 0x100293)
Stack trace of thread 983:
#0 0x00007f03609f96a2 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf6a2)
#1 0x00007f035eabeb3c n/a (radeonsi_dri.so + 0x4edb3c)
#2 0x00007f035eabd308 n/a (radeonsi_dri.so + 0x4ec308)
#3 0x00007f03609f33e9 start_thread (libpthread.so.0 + 0x93e9)
#4 0x00007f0360b0c293 __clone (libc.so.6 + 0x100293)
Stack trace of thread 975:
#0 0x00007f03609f96a2 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf6a2)
#1 0x00007f035eabeb3c n/a (radeonsi_dri.so + 0x4edb3c)
#2 0x00007f035eabd308 n/a (radeonsi_dri.so + 0x4ec308)
#3 0x00007f03609f33e9 start_thread (libpthread.so.0 + 0x93e9)
#4 0x00007f0360b0c293 __clone (libc.so.6 + 0x100293)
Stack trace of thread 992:
#0 0x00007f03609f96a2 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf6a2)
#1 0x00007f035eabeb3c n/a (radeonsi_dri.so + 0x4edb3c)
#2 0x00007f035eabd308 n/a (radeonsi_dri.so + 0x4ec308)
#3 0x00007f03609f33e9 start_thread (libpthread.so.0 + 0x93e9)
#4 0x00007f0360b0c293 __clone (libc.so.6 + 0x100293)
Stack trace of thread 990:
#0 0x00007f03609f96a2 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf6a2)
#1 0x00007f035eabeb3c n/a (radeonsi_dri.so + 0x4edb3c)
#2 0x00007f035eabd308 n/a (radeonsi_dri.so + 0x4ec308)
#3 0x00007f03609f33e9 start_thread (libpthread.so.0 + 0x93e9)
#4 0x00007f0360b0c293 __clone (libc.so.6 + 0x100293)
Stack trace of thread 986:
#0 0x00007f03609f96a2 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf6a2)
#1 0x00007f035eabeb3c n/a (radeonsi_dri.so + 0x4edb3c)
#2 0x00007f035eabd308 n/a (radeonsi_dri.so + 0x4ec308)
#3 0x00007f03609f33e9 start_thread (libpthread.so.0 + 0x93e9)
#4 0x00007f0360b0c293 __clone (libc.so.6 + 0x100293)
Stack trace of thread 985:
#0 0x00007f03609f96a2 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf6a2)
#1 0x00007f035eabeb3c n/a (radeonsi_dri.so + 0x4edb3c)
#2 0x00007f035eabd308 n/a (radeonsi_dri.so + 0x4ec308)
#3 0x00007f03609f33e9 start_thread (libpthread.so.0 + 0x93e9)
#4 0x00007f0360b0c293 __clone (libc.so.6 + 0x100293)
Stack trace of thread 973:
#0 0x00007f03609f96a2 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf6a2)
#1 0x00007f035eabeb3c n/a (radeonsi_dri.so + 0x4edb3c)
#2 0x00007f035eabd308 n/a (radeonsi_dri.so + 0x4ec308)
#3 0x00007f03609f33e9 start_thread (libpthread.so.0 + 0x93e9)
#4 0x00007f0360b0c293 __clone (libc.so.6 + 0x100293)
Stack trace of thread 981:
#0 0x00007f03609f96a2 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf6a2)
#1 0x00007f035eabeb3c n/a (radeonsi_dri.so + 0x4edb3c)
#2 0x00007f035eabd308 n/a (radeonsi_dri.so + 0x4ec308)
#3 0x00007f03609f33e9 start_thread (libpthread.so.0 + 0x93e9)
#4 0x00007f0360b0c293 __clone (libc.so.6 + 0x100293)
Stack trace of thread 987:
#0 0x00007f03609f96a2 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf6a2)
#1 0x00007f035eabeb3c n/a (radeonsi_dri.so + 0x4edb3c)
#2 0x00007f035eabd308 n/a (radeonsi_dri.so + 0x4ec308)
#3 0x00007f03609f33e9 start_thread (libpthread.so.0 + 0x93e9)
#4 0x00007f0360b0c293 __clone (libc.so.6 + 0x100293)
Stack trace of thread 980:
#0 0x00007f03609f96a2 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf6a2)
#1 0x00007f035eabeb3c n/a (radeonsi_dri.so + 0x4edb3c)
#2 0x00007f035eabd308 n/a (radeonsi_dri.so + 0x4ec308)
#3 0x00007f03609f33e9 start_thread (libpthread.so.0 + 0x93e9)
#4 0x00007f0360b0c293 __clone (libc.so.6 + 0x100293)
Stack trace of thread 991:
#0 0x00007f03609f96a2 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf6a2)
#1 0x00007f035eabeb3c n/a (radeonsi_dri.so + 0x4edb3c)
#2 0x00007f035eabd308 n/a (radeonsi_dri.so + 0x4ec308)
#3 0x00007f03609f33e9 start_thread (libpthread.so.0 + 0x93e9)
#4 0x00007f0360b0c293 __clone (libc.so.6 + 0x100293)
Stack trace of thread 989:
#0 0x00007f03609f96a2 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf6a2)
#1 0x00007f035eabeb3c n/a (radeonsi_dri.so + 0x4edb3c)
#2 0x00007f035eabd308 n/a (radeonsi_dri.so + 0x4ec308)
#3 0x00007f03609f33e9 start_thread (libpthread.so.0 + 0x93e9)
#4 0x00007f0360b0c293 __clone (libc.so.6 + 0x100293)
Stack trace of thread 988:
#0 0x00007f03609f96a2 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf6a2)
#1 0x00007f035eabeb3c n/a (radeonsi_dri.so + 0x4edb3c)
#2 0x00007f035eabd308 n/a (radeonsi_dri.so + 0x4ec308)
#3 0x00007f03609f33e9 start_thread (libpthread.so.0 + 0x93e9)
#4 0x00007f0360b0c293 __clone (libc.so.6 + 0x100293)
Stack trace of thread 993:
#0 0x00007f03609f96a2 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf6a2)
#1 0x00007f035eabeb3c n/a (radeonsi_dri.so + 0x4edb3c)
#2 0x00007f035eabd308 n/a (radeonsi_dri.so + 0x4ec308)
#3 0x00007f03609f33e9 start_thread (libpthread.so.0 + 0x93e9)
#4 0x00007f0360b0c293 __clone (libc.so.6 + 0x100293)
GNU gdb (GDB) 10.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/sway...
(No debugging symbols found in /usr/bin/sway)
warning: Can't open file /memfd:wayland-cursor (deleted) during file-backed mapping note processing
warning: Can't open file /run/user/1000/sway-client-oihQbp (deleted) during file-backed mapping note processing
warning: Can't open file /dev/shm/mako-FAlkib (deleted) during file-backed mapping note processing
warning: Can't open file /memfd:xwayland-shared (deleted) during file-backed mapping note processing
warning: Can't open file /memfd:gdk-wayland (deleted) during file-backed mapping note processing
[New LWP 969]
[New LWP 979]
[New LWP 977]
[New LWP 976]
[New LWP 974]
[New LWP 971]
[New LWP 972]
[New LWP 978]
[New LWP 984]
[New LWP 982]
[New LWP 983]
[New LWP 975]
[New LWP 992]
[New LWP 990]
[New LWP 986]
[New LWP 985]
[New LWP 973]
[New LWP 981]
[New LWP 987]
[New LWP 980]
[New LWP 991]
[New LWP 989]
[New LWP 988]
[New LWP 993]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `sway'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000055775cf57056 in ?? ()
[Current thread is 1 (Thread 0x7f035fdda940 (LWP 969))]
(gdb) bt full
#0 0x000055775cf57056 in ()
#1 0x00007f0360cc370e in () at /usr/lib/libwlroots.so.7
#2 0x00007f03603ffacd in () at /usr/lib/libffi.so.7
#3 0x00007f03603ff03a in () at /usr/lib/libffi.so.7
#4 0x00007f0360d10124 in () at /usr/lib/libwayland-server.so.0
#5 0x00007f0360d0b57c in () at /usr/lib/libwayland-server.so.0
#6 0x00007f0360d0e07a in wl_event_loop_dispatch () at /usr/lib/libwayland-server.so.0
#7 0x00007f0360d0bbe7 in wl_display_run () at /usr/lib/libwayland-server.so.0
#8 0x000055775cf5882f in ()
#9 0x00007f0360a34152 in __libc_start_main () at /usr/lib/libc.so.6
#10 0x000055775cf58bae in ()
(gdb)
The backtrace you provided doesn't contain debug symbols. This most likely happens because the Sway binary you're using doesn't have debug information bundled.
Can you try again with a manually compiled Sway binary? See https://github.com/swaywm/sway/wiki/Development-Setup#compiling-as-a-subproject
I am now running sway build using:
# Clone repositories
git clone [email protected]:swaywm/sway.git
cd sway
git clone [email protected]:swaywm/wlroots.git subprojects/wlroots
# Build sway and wlroots
meson build/
ninja -C build/
# Start sway
build/sway/sway
I am using my normal sway config file and swaybar, etc.
I will report back after another crash with the coredumpctl gdb sway and bt full info.
I got a crash when running swaylock with asan:
Feb 05 17:37:53 vic swayidle-start[22715]: ==22715==ERROR: AddressSanitizer: heap-use-after-free on address 0x61300002ffe0 at pc 0x00000040cd29 bp 0x7ffcde6ad240 sp 0x7ffcde6ad238
Feb 05 17:37:53 vic swayidle-start[22715]: WRITE of size 1 at 0x61300002ffe0 thread T0
Feb 05 17:37:53 vic swayidle-start[22715]: #0 0x40cd28 in buffer_release (/nix/store/mzi2aq4c176gyi1g3l8zv6pr2s4r03li-swaylock-1.5/bin/swaylock+0x40cd28)
Feb 05 17:37:53 vic swayidle-start[22715]: #1 0x7f19eafcbb2c in ffi_call_unix64 (/nix/store/z1kwafc0yf8jzhmm8f0j72nc196jl1sq-libffi-3.3/lib/libffi.so.7+0x7b2c)
Feb 05 17:37:53 vic swayidle-start[22715]: #2 0x7f19eafca83b in ffi_call_int (/nix/store/z1kwafc0yf8jzhmm8f0j72nc196jl1sq-libffi-3.3/lib/libffi.so.7+0x683b)
Feb 05 17:37:53 vic swayidle-start[22715]: #3 0x7f19ebc822e1 in wl_closure_invoke (/nix/store/w6rq0kfag1yqb3pj0bi9g84nrv9nbckf-wayland-1.18.0/lib/libwayland-client.so.0+0xa2e1)
Feb 05 17:37:53 vic swayidle-start[22715]: #4 0x7f19ebc7e979 in dispatch_event.isra.0 (/nix/store/w6rq0kfag1yqb3pj0bi9g84nrv9nbckf-wayland-1.18.0/lib/libwayland-client.so.0+0x6979)
Feb 05 17:37:53 vic swayidle-start[22715]: #5 0x7f19ebc8004b in wl_display_dispatch_queue_pending (/nix/store/w6rq0kfag1yqb3pj0bi9g84nrv9nbckf-wayland-1.18.0/lib/libwayland-client.so.0+0x804b)
Feb 05 17:37:53 vic swayidle-start[22715]: #6 0x408c0f in display_in (/nix/store/mzi2aq4c176gyi1g3l8zv6pr2s4r03li-swaylock-1.5/bin/swaylock+0x408c0f)
Feb 05 17:37:53 vic swayidle-start[22715]: #7 0x4086bc in loop_poll (/nix/store/mzi2aq4c176gyi1g3l8zv6pr2s4r03li-swaylock-1.5/bin/swaylock+0x4086bc)
Feb 05 17:37:53 vic swayidle-start[22715]: #8 0x4055c2 in main (/nix/store/mzi2aq4c176gyi1g3l8zv6pr2s4r03li-swaylock-1.5/bin/swaylock+0x4055c2)
Feb 05 17:37:53 vic swayidle-start[22715]: #9 0x7f19ebacddec in __libc_start_main (/nix/store/gafigwfaimlziam6qhw1m8dz4h952g1n-glibc-2.32-35/lib/libc.so.6+0x27dec)
Feb 05 17:37:53 vic swayidle-start[22715]: #10 0x406029 in _start (/nix/store/mzi2aq4c176gyi1g3l8zv6pr2s4r03li-swaylock-1.5/bin/swaylock+0x406029)
Feb 05 17:37:53 vic swayidle-start[22715]: 0x61300002ffe0 is located 288 bytes inside of 360-byte region [0x61300002fec0,0x613000030028)
Feb 05 17:37:53 vic swayidle-start[22715]: freed by thread T0 here:
Feb 05 17:37:53 vic swayidle-start[22715]: #0 0x7f19ebf38b6f in __interceptor_free (/nix/store/sipmc4wnbcws4vahqlf5i06zz7xgnp23-gcc-10.2.0-lib/lib/libasan.so.6+0xacb6f)
Feb 05 17:37:53 vic swayidle-start[22715]: #1 0x7f19eafcbb2c in ffi_call_unix64 (/nix/store/z1kwafc0yf8jzhmm8f0j72nc196jl1sq-libffi-3.3/lib/libffi.so.7+0x7b2c)
Feb 05 17:37:53 vic swayidle-start[22715]: previously allocated by thread T0 here:
Feb 05 17:37:53 vic swayidle-start[22715]: #0 0x7f19ebf39037 in __interceptor_calloc (/nix/store/sipmc4wnbcws4vahqlf5i06zz7xgnp23-gcc-10.2.0-lib/lib/libasan.so.6+0xad037)
Feb 05 17:37:53 vic swayidle-start[22715]: #1 0x40bc23 in handle_global (/nix/store/mzi2aq4c176gyi1g3l8zv6pr2s4r03li-swaylock-1.5/bin/swaylock+0x40bc23)
Feb 05 17:37:53 vic swayidle-start[22715]: #2 0x7f19eafcbb2c in ffi_call_unix64 (/nix/store/z1kwafc0yf8jzhmm8f0j72nc196jl1sq-libffi-3.3/lib/libffi.so.7+0x7b2c)
Feb 05 17:37:53 vic swayidle-start[22715]: SUMMARY: AddressSanitizer: heap-use-after-free (/nix/store/mzi2aq4c176gyi1g3l8zv6pr2s4r03li-swaylock-1.5/bin/swaylock+0x40cd28) in buffer_release
Feb 05 17:37:53 vic swayidle-start[22715]: Shadow bytes around the buggy address:
Feb 05 17:37:53 vic swayidle-start[22715]: 0x0c267fffdfa0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Feb 05 17:37:53 vic swayidle-start[22715]: 0x0c267fffdfb0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Feb 05 17:37:53 vic swayidle-start[22715]: 0x0c267fffdfc0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Feb 05 17:37:53 vic swayidle-start[22715]: 0x0c267fffdfd0: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
Feb 05 17:37:53 vic swayidle-start[22715]: 0x0c267fffdfe0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Feb 05 17:37:53 vic swayidle-start[22715]: =>0x0c267fffdff0: fd fd fd fd fd fd fd fd fd fd fd fd[fd]fd fd fd
Feb 05 17:37:53 vic swayidle-start[22715]: 0x0c267fffe000: fd fd fd fd fd fa fa fa fa fa fa fa fa fa fa fa
Feb 05 17:37:53 vic swayidle-start[22715]: 0x0c267fffe010: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Feb 05 17:37:53 vic swayidle-start[22715]: 0x0c267fffe020: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Feb 05 17:37:53 vic swayidle-start[22715]: 0x0c267fffe030: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Feb 05 17:37:53 vic swayidle-start[22715]: 0x0c267fffe040: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
Feb 05 17:37:53 vic swayidle-start[22715]: Shadow byte legend (one shadow byte represents 8 application bytes):
Feb 05 17:37:53 vic swayidle-start[22715]: Addressable: 00
Feb 05 17:37:53 vic swayidle-start[22715]: Partially addressable: 01 02 03 04 05 06 07
Feb 05 17:37:53 vic swayidle-start[22715]: Heap left redzone: fa
Feb 05 17:37:53 vic swayidle-start[22715]: Freed heap region: fd
Feb 05 17:37:53 vic swayidle-start[22715]: Stack left redzone: f1
Feb 05 17:37:53 vic swayidle-start[22715]: Stack mid redzone: f2
Feb 05 17:37:53 vic swayidle-start[22715]: Stack right redzone: f3
Feb 05 17:37:53 vic swayidle-start[22715]: Stack after return: f5
Feb 05 17:37:53 vic swayidle-start[22715]: Stack use after scope: f8
Feb 05 17:37:53 vic swayidle-start[22715]: Global redzone: f9
Feb 05 17:37:53 vic swayidle-start[22715]: Global init order: f6
Feb 05 17:37:53 vic swayidle-start[22715]: Poisoned by user: f7
Feb 05 17:37:53 vic swayidle-start[22715]: Container overflow: fc
Feb 05 17:37:53 vic swayidle-start[22715]: Array cookie: ac
Feb 05 17:37:53 vic swayidle-start[22715]: Intra object redzone: bb
Feb 05 17:37:53 vic swayidle-start[22715]: ASan internal: fe
Feb 05 17:37:53 vic swayidle-start[22715]: Left alloca redzone: ca
Feb 05 17:37:53 vic swayidle-start[22715]: Right alloca redzone: cb
Feb 05 17:37:53 vic swayidle-start[22715]: Shadow gap: cc
Feb 05 17:37:53 vic swayidle-start[22715]: ==22715==ABORTING
It looks like asan usage did not trigger a coredump, so I dont have a crashdump.
swaylock 1.5 sway 1.5.1 wlroots 0.12.0
I have a new coredump:
λ ~/ coredumpctl gdb /home/patrick/sway/build/sway/sway
PID: 1121 (sway)
UID: 1000 (patrick)
GID: 1000 (patrick)
Signal: 11 (SEGV)
Timestamp: Sun 2021-02-07 14:18:14 CET (3min 20s ago)
Command Line: /home/patrick/sway/build/sway/sway
Executable: /home/patrick/sway/build/sway/sway
Control Group: /user.slice/user-1000.slice/session-1.scope
Unit: session-1.scope
Slice: user-1000.slice
Session: 1
Owner UID: 1000 (patrick)
Boot ID: 007d57d10c55487e9223434a8192a339
Machine ID: 9750f21e4965473682827a1680010c18
Hostname: plato
Storage: /var/lib/systemd/coredump/core.sway.1000.007d57d10c55487e9223434a8192a339.1121.1612703894000000.zst
Message: Process 1121 (sway) of user 1000 dumped core.
Stack trace of thread 1121:
#0 0x000055f4e4619d3d n/a (/home/patrick/sway/build/sway/sway + 0x67d3d)
#1 0x000055f4e45ebcde n/a (/home/patrick/sway/build/sway/sway + 0x39cde)
#2 0x000055f4e45dfc3a n/a (/home/patrick/sway/build/sway/sway + 0x2dc3a)
#3 0x00007fab42e7f09a n/a (/home/patrick/sway/build/subprojects/wlroots/libwlroots.so.7 + 0x9209a)
#4 0x00007fab42e5d9a1 n/a (/home/patrick/sway/build/subprojects/wlroots/libwlroots.so.7 + 0x709a1)
#5 0x00007fab41dfeacd n/a (libffi.so.7 + 0x6acd)
#6 0x00007fab41dfe03a n/a (libffi.so.7 + 0x603a)
#7 0x00007fab427d3124 n/a (libwayland-server.so.0 + 0xd124)
#8 0x00007fab427ce57c n/a (libwayland-server.so.0 + 0x857c)
#9 0x00007fab427d107a wl_event_loop_dispatch (libwayland-server.so.0 + 0xb07a)
#10 0x00007fab427cebe7 wl_display_run (libwayland-server.so.0 + 0x8be7)
#11 0x000055f4e45d2b7d n/a (/home/patrick/sway/build/sway/sway + 0x20b7d)
#12 0x000055f4e45d201d n/a (/home/patrick/sway/build/sway/sway + 0x2001d)
#13 0x00007fab425a0b25 __libc_start_main (libc.so.6 + 0x27b25)
#14 0x000055f4e45c355e n/a (/home/patrick/sway/build/sway/sway + 0x1155e)
GNU gdb (GDB) 10.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/patrick/sway/build/sway/sway...
warning: Can't open file /run/user/1000/sway-client-dVaQFi (deleted) during file-backed mapping note processing
warning: Can't open file /memfd:wayland-cursor (deleted) during file-backed mapping note processing
warning: Can't open file /memfd:gdk-wayland (deleted) during file-backed mapping note processing
[New LWP 1121]
[New LWP 1128]
[New LWP 1137]
[New LWP 1153]
[New LWP 1125]
[New LWP 1132]
[New LWP 1158]
[New LWP 1159]
[New LWP 1135]
[New LWP 1146]
[New LWP 1138]
[New LWP 1127]
[New LWP 1139]
[New LWP 1136]
[New LWP 1140]
[New LWP 1148]
[New LWP 1144]
[New LWP 1142]
[New LWP 1130]
[New LWP 1141]
[New LWP 1150]
[New LWP 1155]
[New LWP 1145]
[New LWP 1134]
[New LWP 1143]
[New LWP 1152]
[New LWP 1166]
[New LWP 1156]
[New LWP 1157]
[New LWP 1149]
[New LWP 1126]
[New LWP 1123]
[New LWP 1131]
[New LWP 1147]
[New LWP 1151]
[New LWP 1160]
[New LWP 1124]
[New LWP 1162]
[New LWP 1154]
[New LWP 1133]
[New LWP 1161]
[New LWP 1165]
[New LWP 1163]
[New LWP 1129]
[New LWP 1164]
Warning: couldn't activate thread debugging using libthread_db: Cannot find new threads: generic error
warning: File "/usr/lib/libthread_db-1.0.so" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
--Type <RET> for more, q to quit, c to continue without paging--
After this I press c, and get:
--Type <RET> for more, q to quit, c to continue without paging--c
To enable execution of this file add
add-auto-load-safe-path /usr/lib/libthread_db-1.0.so
line to your configuration file "/home/patrick/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/patrick/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual. E.g., run from the shell:
info "(gdb)Auto-loading safe path"
warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `/home/patrick/sway/build/sway/sway'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000055f4e4619d3d in node_is_view (node=0x0) at ../sway/tree/node.c:41
41 ../sway/tree/node.c: No such file or directory.
[Current thread is 1 (Thread 0x7fab41938980 (LWP 1121))]
(gdb)
After typing bt full:
(gdb) bt full
#0 0x000055f4e4619d3d in node_is_view (node=0x0) at ../sway/tree/node.c:41
#1 0x000055f4e45ebcde in seat_set_exclusive_client (seat=0x55f4e6812cf0, client=0x55f4e6fe07b0) at ../sway/input/seat.c:1280
focus = 0x0
now = {tv_sec = 140725458161288, tv_nsec = 140725458161504}
point = 0x7ffd32f1ce90
#2 0x000055f4e45dfc3a in handle_inhibit_activate (listener=0x55f4e67fdfd8, data=0x55f4e680f6c0) at ../sway/input/input-manager.c:284
input_manager = 0x55f4e67fdf80
seat = 0x55f4e6812cf0
#3 0x00007fab42e7f09a in wlr_signal_emit_safe (signal=0x55f4e680f6f0, data=0x55f4e680f6c0) at ../subprojects/wlroots/util/signal.c:29
pos = 0x55f4e67fdfd8
l = 0x55f4e67fdfd8
cursor = {link = {prev = 0x55f4e67fdfd8, next = 0x7ffd32f1cd70}, notify = 0x7fab42e7efe4 <handle_noop>}
end = {link = {prev = 0x7ffd32f1cd50, next = 0x55f4e680f6f0}, notify = 0x7fab42e7efe4 <handle_noop>}
#4 0x00007fab42e5d9a1 in inhibit_manager_get_inhibitor (client=0x55f4e6fe07b0, resource=0x55f4e6cc7630, id=3) at ../subprojects/wlroots/types/wlr_input_inhibitor.c:74
manager = 0x55f4e680f6c0
wl_resource = 0x55f4e69e8740
#5 0x00007fab41dfeacd in () at /usr/lib/libffi.so.7
#6 0x00007fab41dfe03a in () at /usr/lib/libffi.so.7
#7 0x00007fab427d3124 in () at /usr/lib/libwayland-server.so.0
#8 0x00007fab427ce57c in () at /usr/lib/libwayland-server.so.0
#9 0x00007fab427d107a in wl_event_loop_dispatch () at /usr/lib/libwayland-server.so.0
#10 0x00007fab427cebe7 in wl_display_run () at /usr/lib/libwayland-server.so.0
#11 0x000055f4e45d2b7d in server_run (server=0x55f4e464a340 <server>) at ../sway/server.c:260
#12 0x000055f4e45d201d in main (argc=1, argv=0x7ffd32f1d4f8) at ../sway/main.c:431
verbose = 0
debug = 0
validate = 0
allow_unsupported_gpu = 0
long_options =
{{name = 0x55f4e462c190 "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x55f4e462c195 "config", has_arg = 1, flag = 0x0, val = 99}, {name = 0x55f4e462c19c "validate", has_arg = 0, flag = 0x0, val = 67}, {name = 0x55f4e462c1a5 "debug", has_arg = 0, flag = 0x0, val = 100}, {name = 0x55f4e462c1ab "version", has_arg = 0, flag = 0x0, val = 118}, {name = 0x55f4e462c1b3 "verbose", has_arg = 0, flag = 0x0, val = 86}, {name = 0x55f4e462c1bb "get-socketpath", has_arg = 0, flag = 0x0, val = 112}, {name = 0x55f4e462c1ca "unsupported-gpu", has_arg = 0, flag = 0x0, val = 117}, {name = 0x55f4e462c1da "my-next-gpu-wont-be-nvidia", has_arg = 0, flag = 0x0, val = 117}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}}
config_path = 0x0
usage = 0x55f4e462bc20 "Usage: sway [options] [command]\n\n -h, --help", ' ' <repeats 13 times>, "Show help message and quit.\n -c, --config <config> Specify a config file.\n -C, --validate Check the validity of the config file, th"...
c = -1
(gdb)
I do hope this is useful for you... and just for your info:
sway version 1.5-89b4bc4b (Feb 3 2021, branch 'master') swaybar version 1.5.1 swaylock version 1.4
It seems easy to reproduce. I simple unplug the power connector and the external monitor. Then I close the lid. I wait for about a minute. After opening I get the error as presented above.
I do understand that this is not an issue that is easy to debug. But since it is extremely serious, I would humbly suggest that the developers add a very prominent warning to swaylock to ensure that people cannot expect their screens to stay locked after hibernation. This way, people can at least take precautions such as disallowing that untrusted third parties initiate hibernation (like a passer-by closing a laptop lid).
, I would humbly suggest that the developers add a very prominent warning to swaylock to ensure that people cannot expect their screens to stay locked after hibernation.
We are not going to add such a warning. swaylock is a normal application, and it crashing simply means that its window goes away - hibernation isn't the only swaylock crash bug. See https://github.com/swaywm/wlroots/issues/2706 for discussion on ways to "harden" the screenlocker usecase.
It should of course be noted that from a security standpoint, physical access to a running computer fully logged in (which it is when it is merely showing a lockscreen) means "game over", so if you are very security conscious you should log out to have encrypted home folders unmount, or power off to have full disk encryption be of use.
Kenny Levinsen @.***> writes:
It should of course be noted that from a security standpoint, physical access to a running computer fully logged in (which it is when it is merely showing a lockscreen) means "game over", so if you are very security conscious you should log out to have encrypted home folders unmount, or power off to have full disk encryption be of use.
I have a hard time understanding this threat model. Of course, full physical access can mean game over. But if that's the threat model, there's surely no point having a screen locker at all? What's swaylock's raison d'être if it's not locking a person with casual physical access to the device out of completely unrestricted access to the logged in user's session?
What's swaylock's raison d'être if it's not locking a person with casual physical access to the device out of completely unrestricted access to the logged in user's session?
Read the issue I linked.