Description of problem: I have spotted this recently (VM) that whenever I leave the VM unattended and let the screen dim and lock. It is then impossible to get back to the session because the screen stays black and unresponsive. The VM even does not respond to the Ctrl-Alt-F3 combo to switch to the console and it must be restarted. Version-Release number of selected component (if applicable): kscreenlocker-5.22.5-1 How reproducible: Always Steps to Reproduce: 1. Leave the KDE session alone until it locks screen and dims. Actual results: The screen stays black and does not respond to anything to unlock. Expected results: The screen should respond to keys or mouse moves to unlock. Additional info: This error is reported to journalctl: Oct 13 13:07:09 fedora kernel: kscreenlocker_g[3293]: segfault at 18 ip 00007f72715c8bcf sp 00007ffe86baa480 error 4 in libLayerShellQtInterface.so.5.22.5[7f72715c7000+3000] Oct 13 13:07:09 fedora kernel: Code: 89 c6 48 89 c5 4c 89 54 24 10 e8 cc e9 ff ff 48 89 ef e8 e4 ea ff ff 4c 89 e7 41 89 c5 e8 19 ea ff ff 48 8b 74 24 10 4c 89 f7 <4c> 8b 48 18 49 8b 44 24 30 4c 8b 40 18 4c 89 4c 24 08 4c 89 04 24 Oct 13 13:07:09 fedora audit[3293]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=3293 comm="kscreenlocker_g" exe="/usr/libexec/kscreenlocker_greet" sig=11 res=1
Proposed as a Blocker for 35-final by Fedora user lruzicka using the blocker tracking app because: I am proposing this a blocker because it might violate the following release criterion "Shutdown, reboot, login, logout" as login to the session is disabled when this issue occurs.
Possible candidates from upstream: KScreenLocker: https://invent.kde.org/plasma/kscreenlocker/-/commit/e31b987ba64c74f563fc0f071eda117d99913f15 LayerShellQt: https://invent.kde.org/plasma/layer-shell-qt/-/commit/4a439143baf75b9a00cf17a3b7a34ae9ac93c68a
I can see this consistently also in F34 on bare metal. I have no problem after a simple screen locking, but when the screen goes in power saving, at the resume I get exactly the same message reported here: https://forums.opensuse.org/showthread.php/518831-The-screen-locker-is-broken-and-unlocking-is-not-possible-anymore I can see some segfault related to kscreenlocker in the logs, I'll try to post them here.
We had a report in chat that this isn't observed in 5.22.90 on X11. It would be good to know if people are seeing this just on Wayland or on X11, too.
I didn't see this happen in my vm. I let it running for a few hours with bunch of screen dims/locks and I was always able to wake the vm screen up and get to the running session just fine. The only difference that comes to my mind - I am using virtio (3d) with enabled OpenGl in my vm, can test it without the hw gl later. kscreenlocker-5.22.5-1, Wayland session.
Created attachment 1832625 [details] kscreenlocker_g segfault in journalctl
I haven't seen this in my testing in VMs either, and I quite often let them go idle like this. I'm also using virtio in a qemu VM, like František.
Update: since the segfaults in the log I provided seem related to the patches noticed in comment#2, I have made scratch builds of kscreenlocker and layershellqt 5.23.0 for F34 and updated my system. Now at resume from power saving I don't have segfaults anymore, but the greeter is not showed, only a black screen with mouse pointer, so I'm not sure if backporting those patches will make any enhancement.
(In reply to Adam Williamson from comment #7) > I haven't seen this in my testing in VMs either, and I quite often let them > go idle like this. I'm also using virtio in a qemu VM, like František. My VM is using the QXL driver, will try the virtio driver tomorrow to see if that makes a difference.
I tried to reproduce this today on a bare metal machine (AMD processor) and on a virtio based VM (no acceleration), but I could not reproduce it. KScreenLocker behaved normally. It seems that this might be limited to certain configuration, either on a VM or real hardware.
(In reply to Lukas Ruzicka from comment #10) > I tried to reproduce this today on a bare metal machine (AMD processor) and > on a virtio based VM (no acceleration), but I could not reproduce it. > KScreenLocker behaved normally. It seems that this might be limited to > certain configuration, either on a VM or real hardware. So, I wasn't able to reproduce it on Intel (Sandy Bridge, mesa/crocus) neither.
-4 in https://pagure.io/fedora-qa/blocker-review/issue/539 , marking rejected.
I quickly tested with a qxl and virtio driver, but didn't see the issue.
Seems fixed by https://bodhi.fedoraproject.org/updates/FEDORA-2021-f7d19c8901
FEDORA-2021-f7d19c8901 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-f7d19c8901
FEDORA-2021-f7d19c8901 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.