Swaylock crashes after returning from hybernation

hanckmann commented 3 years ago

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).

hanckmann commented 3 years ago

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). swaylock-crash

Xyene commented 3 years ago

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.

hanckmann commented 3 years ago

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]

Xyene commented 3 years ago

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.

hanckmann commented 3 years ago

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)

emersion commented 3 years ago

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

hanckmann commented 3 years ago

I am now running sway build using:

# Clone repositories
git clone git@github.com:swaywm/sway.git
cd sway
git clone git@github.com: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.

baloo commented 3 years ago

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

hanckmann commented 3 years ago

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.

gspr commented 3 years ago

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).

kennylevinsen commented 3 years ago

, 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.

gspr commented 3 years ago

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?

kennylevinsen commented 3 years ago

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.

swaywm / swaylock

Swaylock crashes after returning from hybernation #164