Screen sometimes locks multiples times requiring several unlocks
e00E opened this issue · 16 comments
I configure sway to lock my screen on timeout or suspend:
exec swayidle -w \
timeout 7200 'swaylock -f' \
before-sleep 'swaylock -f'
Sometimes when I try to unlock the machine I need to enter my password multiple times. I am certain I am typing it correctly and the failure message does not show up.
I suspect this happens when I suspend the machine when it is already locked, using a hardware button. However, when I just tested this for this bug report, I could not reproduce it again, yet it happened to me a day ago and I have not updated anything since then.
This is unlikely, as the compositor won't allow multiple input inhibitors to be active at the same time.
Is it possible that the next lock screen is queued up and immediately appears when I unlock the previous? What does swaylock do if it attempts to lock when the screen is already locked?
Is there a place I should check for logs the next time this happens to me?
Is it possible that the next lock screen is queued up and immediately appears when I unlock the previous?
No, it would get disconnected.
What does swaylock do if it attempts to lock when the screen is already locked?
https://github.com/swaywm/swaylock/blob/master/main.c#L1155
Is there a place I should check for logs the next time this happens to me?
sway -d 2>&1 >sway.log
Though this produces lots of logs
Hi,
I'm experiencing the same problems and am able to reproduce it consistently with the following steps:
- wait until laptop locks for being idle
- close the laptop lid
- wait until suspension has kicked in
- open laptop lid, I now have to unlock twice
I'm using arch with community/sway 1.1.1-3 on a lenovo thinkpad. I was also capturing the sway debug info but it's quite empty See sway.log.txt.gz for details.
This is my lock config:
exec swayidle -w \
timeout 60 'swaylock-fancy -p' \
timeout 300 'swaymsg "output * dpms off"' \
resume 'swaymsg "output * dpms on"' \
before-sleep 'swaylock-fancy -p'
edit: full sway log.
Mine sway has same issue. If I leave it untouched for few hours it makes me unlock several times.
I added the --daemonize flag to everywhere I was using swaylock (actually I just ended up putting it in the swaylock config) and it seems to have solved the issue for me.
Looks like the swayidle example in the default config was updated last year to add those flags, so perhaps it actually helps?
I also have this issue. To reproduce the double lock, I set a swayidle lock timeout of 5 seconds, manually locked the screen, waited at least 5 seconds, and unlocked the screen. The screen immediately locked a second time.
swaylock does not use the --daemonize option.
Edit: Removing the -w flag from swayidle fixes the double lock, but prevents monitor dpms. For context, my lock script includes
swayidle \
timeout 5 'swaymsg --pretty "output * dpms off"' \
resume 'swaymsg --pretty "output * dpms on"' &
to quickly blank the display when locked. Without -w on the usual swayidle, the monitor stops blanking, and will not blank again, after the lock timeout.
Edit2: I daemonized my lock script and added the -w flag to swayidle. No more multiple locks, and my lockscreen blanking script works.
I see a very similar issue, only that once 2 swaylock are running, I can't unlock them anymore. When logging in from another machine I see:
$ ps aux | grep sway
user 553 0.0 0.0 9620 2876 tty1 S+ 06:41 0:00 /bin/sh /usr/local/bin/sway-run.sh
user 556 1.4 1.4 2073688 232884 tty1 Sl+ 06:41 12:29 sway
user 579 0.0 0.2 58492 48940 tty1 S+ 06:41 0:00 swaybg -o * -i /usr/share/backgrounds/sway/Sway_Wallpaper_Blue_1920x1080.png -m fill
user 583 0.0 0.0 6364 3252 ? S 06:41 0:00 swayidle -w timeout 300 swaylock -f -c 000000 timeout 600 swaymsg "output * dpms off" resume swaymsg "output * dpms on" before-sleep swaylock -f -c 000000
user 41024 0.0 0.0 25708 7064 ? S 19:36 0:00 swaylock -f -c 000000
user 41025 0.0 0.2 57172 43616 ? Ss 19:36 0:00 swaylock -f -c 000000
This is with sway-1.6 on Arch Linux.
I see a very similar issue, only that once 2 swaylock are running, I can't unlock them anymore.
This has happened to me repeatedly. I have to login via getty or ssh and kill swaylock, to get back.
For me this only happens on my laptop. I assume the first swaylock is started when it locks after the set time and the second one is started when the computer goes into sleep/hibernation.
I have the same problem, both on my desktop and laptop. And I can see that two, sometimes three swaylock processes running when I log in over ssh. Wasn't able to reproduce it reliably though.
Sway 1.5.1 on Debian Bullseye.
I can now reproduce the issue after pretty much every hibernate of my machine with the following sway config snippet and swaylock 1.6-2 (arch linux):
exec swayidle -w \
timeout 300 'swaylock -f -c 000000' \
timeout 600 'swaymsg "output * dpms off"' \
resume 'swaymsg "output * dpms on"' \
before-sleep 'swaylock -f -c 000000'
To resolve it I have to SSH into the machine, pkill swaylock and then manually do a swaymsg * dpms on to get the screen back.
I'm running into the same issue, wanted to share the following log:
[nix-shell:~]$ coredumpctl debug swaylock
PID: 160674 (swaylock)
UID: 1000 (douglas)
GID: 100 (users)
Signal: 11 (SEGV)
Timestamp: Mon 2024-03-04 08:34:24 PST (5min ago)
Command Line: /nix/store/1zq038azrag004w6n606jy1mxclhlcgj-swaylock-effects-1.7.0.0/bin/swaylock -elfF -s fill -i /nix/store/2hbic09m3cnlkqww8slj6hmdma7z5hm7-4Xqpx6R.png
Executable: /nix/store/1zq038azrag004w6n606jy1mxclhlcgj-swaylock-effects-1.7.0.0/bin/swaylock
Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/swayidle.service
Unit: user@1000.service
User Unit: swayidle.service
Slice: user-1000.slice
Owner UID: 1000 (douglas)
Boot ID: e0ca1ebec42c4d68aba263dfa6f06af3
Machine ID: daaeccc0975f4a8680602a7f5814fb5b
Hostname: beast
Storage: /var/lib/systemd/coredump/core.swaylock.1000.e0ca1ebec42c4d68aba263dfa6f06af3.160674.1709570064000000.zst (present)
Size on Disk: 9.3M
Message: Process 160674 (swaylock) of user 1000 dumped core.
Module libbrotlicommon.so.1 without build-id.
Module libselinux.so.1 without build-id.
Module libXdmcp.so.6 without build-id.
Module libXau.so.6 without build-id.
Module libexpat.so.1 without build-id.
Module libbrotlidec.so.1 without build-id.
Module libbz2.so.1 without build-id.
Module libaudit.so.1 without build-id.
Module libpcre2-8.so.0 without build-id.
Module libffi.so.8 without build-id.
Module libjpeg.so.62 without build-id.
Module libxcb-shm.so.0 without build-id.
Module libxcb-render.so.0 without build-id.
Module libxcb.so.1 without build-id.
Module libXrender.so.1 without build-id.
Module libXext.so.6 without build-id.
Module libX11.so.6 without build-id.
Module libfreetype.so.6 without build-id.
Module libfontconfig.so.1 without build-id.
Module libpng16.so.16 without build-id.
Module libz.so.1 without build-id.
Module libgomp.so.1 without build-id.
Module libpam.so.0 without build-id.
Module libxkbcommon.so.0 without build-id.
Module swaylock without build-id.
Stack trace of thread 160674:
#0 0x0000000000408abb handle_screencopy_frame_failed (swaylock + 0x8abb)
#1 0x00007fa3b890c052 ffi_call_unix64 (libffi.so.8 + 0xa052)
#2 0x00007fa3b8909ec5 ffi_call_int (libffi.so.8 + 0x7ec5)
#3 0x00007fa3b890aab8 ffi_call (libffi.so.8 + 0x8ab8)
#4 0x00007fa3b91f97a1 wl_closure_invoke (libwayland-client.so.0 + 0xa7a1)
#5 0x00007fa3b91f5bd9 dispatch_event.isra.0 (libwayland-client.so.0 + 0x6bd9)
#6 0x00007fa3b91f7524 wl_display_dispatch_queue_pending (libwayland-client.so.0 + 0x8524)
#7 0x00007fa3b91f7adf wl_display_roundtrip_queue (libwayland-client.so.0 + 0x8adf)
#8 0x00007fa3b890c052 ffi_call_unix64 (libffi.so.8 + 0xa052)
#9 0x00007fa3b8909ec5 ffi_call_int (libffi.so.8 + 0x7ec5)
#10 0x00007fa3b890aab8 ffi_call (libffi.so.8 + 0x8ab8)
#11 0x00007fa3b91f97a1 wl_closure_invoke (libwayland-client.so.0 + 0xa7a1)
#12 0x00007fa3b91f5bd9 dispatch_event.isra.0 (libwayland-client.so.0 + 0x6bd9)
#13 0x00007fa3b91f7524 wl_display_dispatch_queue_pending (libwayland-client.so.0 + 0x8524)
#14 0x0000000000408c80 display_in (swaylock + 0x8c80)
#15 0x000000000040855f loop_poll (swaylock + 0x855f)
#16 0x00000000004063bf main (swaylock + 0x63bf)
#17 0x00007fa3b8fcd0ce __libc_start_call_main (libc.so.6 + 0x280ce)
#18 0x00007fa3b8fcd189 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x28189)
#19 0x00000000004068f5 _start (swaylock + 0x68f5)
Stack trace of thread 160677:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
Stack trace of thread 160675:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
Stack trace of thread 160678:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
Stack trace of thread 160681:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
Stack trace of thread 160684:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
Stack trace of thread 160680:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
Stack trace of thread 160683:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
Stack trace of thread 160679:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
Stack trace of thread 160685:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
Stack trace of thread 160686:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
Stack trace of thread 160687:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
Stack trace of thread 160689:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
Stack trace of thread 160693:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
Stack trace of thread 160691:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
Stack trace of thread 160694:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
Stack trace of thread 160690:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
Stack trace of thread 160676:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
Stack trace of thread 160688:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
Stack trace of thread 160697:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
Stack trace of thread 160696:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
Stack trace of thread 160695:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
Stack trace of thread 160682:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
Stack trace of thread 160698:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
Stack trace of thread 160700:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
Stack trace of thread 160692:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
Stack trace of thread 160702:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
Stack trace of thread 160704:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
Stack trace of thread 160699:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
Stack trace of thread 160705:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
Stack trace of thread 160703:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
Stack trace of thread 160701:
#0 0x00007fa3b91b309e gomp_barrier_wait_end (libgomp.so.1 + 0x2309e)
#1 0x00007fa3b91b06f8 gomp_thread_start (libgomp.so.1 + 0x206f8)
#2 0x00007fa3b9030383 start_thread (libc.so.6 + 0x8b383)
#3 0x00007fa3b90b300c __clone3 (libc.so.6 + 0x10e00c)
ELF object binary architecture: AMD x86-64
GNU gdb (GDB) 14.1
Copyright (C) 2023 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-unknown-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 /nix/store/1zq038azrag004w6n606jy1mxclhlcgj-swaylock-effects-1.7.0.0/bin/swaylock...
(No debugging symbols found in /nix/store/1zq038azrag004w6n606jy1mxclhlcgj-swaylock-effects-1.7.0.0/bin/swaylock)
warning: Can't open file /dev/shm/swaylock-273a2-37ff0ffd (deleted) during file-backed mapping note processing
warning: Can't open file /dev/shm/swaylock-shm (deleted) during file-backed mapping note processing
warning: Can't open file /dev/shm/swaylock-273a2-39b561fd (deleted) during file-backed mapping note processing
[New LWP 160674]
[New LWP 160677]
[New LWP 160675]
[New LWP 160678]
[New LWP 160681]
[New LWP 160684]
[New LWP 160680]
[New LWP 160683]
[New LWP 160679]
[New LWP 160685]
[New LWP 160686]
[New LWP 160687]
[New LWP 160689]
[New LWP 160693]
[New LWP 160691]
[New LWP 160694]
[New LWP 160690]
[New LWP 160676]
[New LWP 160688]
[New LWP 160697]
[New LWP 160696]
[New LWP 160695]
[New LWP 160682]
[New LWP 160698]
[New LWP 160700]
[New LWP 160692]
[New LWP 160702]
[New LWP 160704]
[New LWP 160699]
[New LWP 160705]
[New LWP 160703]
[New LWP 160701]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/nix/store/8mc30d49ghc8m5z96yz39srlhg5s9sjj-glibc-2.38-44/lib/libthread_db.so.1".
Core was generated by `/nix/store/1zq038azrag004w6n606jy1mxclhlcgj-swaylock-effects-1.7.0.0/bin/swaylo'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000408abb in handle_screencopy_frame_failed ()
[Current thread is 1 (Thread 0x7fa3b86a2a40 (LWP 160674))]
(gdb) bt
#0 0x0000000000408abb in handle_screencopy_frame_failed ()
#1 0x00007fa3b890c052 in ffi_call_unix64 () from /nix/store/5r3r06j8hzvb2cm0sjhdadgdmzrfh3nj-libffi-3.4.4/lib/libffi.so.8
#2 0x00007fa3b8909ec5 in ffi_call_int () from /nix/store/5r3r06j8hzvb2cm0sjhdadgdmzrfh3nj-libffi-3.4.4/lib/libffi.so.8
#3 0x00007fa3b890aab8 in ffi_call () from /nix/store/5r3r06j8hzvb2cm0sjhdadgdmzrfh3nj-libffi-3.4.4/lib/libffi.so.8
#4 0x00007fa3b91f97a1 in wl_closure_invoke ()
from /nix/store/1iixlnbx1rh7mrwdr5javns99cylgikr-wayland-1.22.0/lib/libwayland-client.so.0
#5 0x00007fa3b91f5bd9 in dispatch_event.isra ()
from /nix/store/1iixlnbx1rh7mrwdr5javns99cylgikr-wayland-1.22.0/lib/libwayland-client.so.0
#6 0x00007fa3b91f7524 in wl_display_dispatch_queue_pending ()
from /nix/store/1iixlnbx1rh7mrwdr5javns99cylgikr-wayland-1.22.0/lib/libwayland-client.so.0
#7 0x00007fa3b91f7adf in wl_display_roundtrip_queue ()
from /nix/store/1iixlnbx1rh7mrwdr5javns99cylgikr-wayland-1.22.0/lib/libwayland-client.so.0
#8 0x00007fa3b890c052 in ffi_call_unix64 () from /nix/store/5r3r06j8hzvb2cm0sjhdadgdmzrfh3nj-libffi-3.4.4/lib/libffi.so.8
#9 0x00007fa3b8909ec5 in ffi_call_int () from /nix/store/5r3r06j8hzvb2cm0sjhdadgdmzrfh3nj-libffi-3.4.4/lib/libffi.so.8
#10 0x00007fa3b890aab8 in ffi_call () from /nix/store/5r3r06j8hzvb2cm0sjhdadgdmzrfh3nj-libffi-3.4.4/lib/libffi.so.8
#11 0x00007fa3b91f97a1 in wl_closure_invoke ()
from /nix/store/1iixlnbx1rh7mrwdr5javns99cylgikr-wayland-1.22.0/lib/libwayland-client.so.0
#12 0x00007fa3b91f5bd9 in dispatch_event.isra ()
from /nix/store/1iixlnbx1rh7mrwdr5javns99cylgikr-wayland-1.22.0/lib/libwayland-client.so.0
#13 0x00007fa3b91f7524 in wl_display_dispatch_queue_pending ()
from /nix/store/1iixlnbx1rh7mrwdr5javns99cylgikr-wayland-1.22.0/lib/libwayland-client.so.0
#14 0x0000000000408c80 in display_in ()
#15 0x000000000040855f in loop_poll ()
#16 0x00000000004063bf in main ()
I'm having this happen on a desktop machine, but the problem specifically happens after turning the monitor off, and then turning it back on again.
I've actually been experiencing this same issue for at least a year, across sway, hyprland, swaylock, and swaylock-effects (though I've only recently started experiencing the red screen after switching to swaylock-effects, before it was a black screen).
Some confounding factors: up until recently, this would completely freeze my display (with logs in dmesg about failure to activate the display), though the freezing was fixed in the latest nvidia drivers (yes, I'm using nvidia).
I wonder if it's also related to the issue where hyprland comes back on virtual desktop 4 instead of the last active virtual desktop (meaning it's related to the handling of displays that went away and come back)
@dmayle This bug tracker is only for swaylock, and this ticket was about swaylock being started multiple times in a row by swayidle due to user configuration issues.
You are sharing a coredump that happens in code that only exists in swaylock-effects, which you should report to swaylock-effects instead.
Hi @kennylevinsen , sorry for the confusion, I followed referrals from one ticket to another, and this was not where I originally intended to post this traceback. With that being said, I have the exact same problem with original swaylock (even using the daemonize flag), so I'll revert to that config and share both tracebacks at the original source.