https://bugs.kde.org/show_bug.cgi?id=379521
Bug ID: 379521
Summary: Kscreenlocker takes a full minute until it is
responsive
Product: kscreenlocker
Version: unspecified
Platform: Archlinux Packages
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: greeter
Assignee: plasma-b...@kde.org
Reporter: spa...@modanese.net
CC: bhus...@gmail.com, mgraess...@kde.org
Target Milestone: ---
Created attachment 105347
--> https://bugs.kde.org/attachment.cgi?id=105347&action=edit
GDB backtrace
Version: 5.9.5 (latest on Arch Linux x86_64).
After my PC is up and running for a few (4~5+) hours, kscreenlocker_greet takes
a full minute until it is responsive and reacts to keyboard or mouse input. And
yes, I've actually timed it; the standard deviation was +/- 2 seconds.
During that minute, CPU usages spikes to 100% and reserved memory (in top)
eventually exceeds 500 MB. I've also noticed memory usage increases every 5
seconds or so, and by 10-20 MB increments. When the program's responsive again,
CPU returns to normal, while memory usage is reduced to around 400 MB.
The problem happens independent of how kscreenlocker_greet is invoked: by
locking the screen; letting it happen automatically because of inactivity; or
even by running it from the terminal directly (with or without the '--testing'
option; it doesn't matter).
Sending a HUP signal to the process or using loginctl to unlock the session is
a workaround, but very annoying.
GDB backtrace (attached) indicates the program is stuck waiting for...
something.
Since the time kscreenlocker_greet is unresponsive is so precise, I suspect
it's a timeout expiring which causes it to be responsive again.
--
You are receiving this mail because:
You are watching all bug changes.
