Bug 347772

Does this happen just in kscreenlocker_greet or also plasmashell? I suspect the time dataengine being too generous with QTimeZones or Qt not caching it (properly), but that would probably also affect plasmashell's digital-clock.

(In reply to Kai Uwe Broulik from comment #1)
> Does this happen just in kscreenlocker_greet or also plasmashell? I suspect
> the time dataengine being too generous with QTimeZones or Qt not caching it
> (properly), but that would probably also affect plasmashell's digital-clock.

This appears to only be happening in kscreenlocker_greet.  I have not witnessed /usr/bin/plasmashell utilizing 100% CPU.

I turned off the compositor (System Settings -> Display and Monitor -> Compositor and unchecked the "Enable compositor on startup") and now kscreenlocker_greet no longer consumes 100% of my CPU.  The moment I turn compositor back on, kscreenlocker_greet will hog a CPU.

I can confirm the bug. What's interesting is that it seems to happen randomly - it could happen every dozen of minutes or hours or it could not happen for days if I'm lucky. In my case it also leads to https://bugs.kde.org/show_bug.cgi?id=338999 and all I can do is REISUB because even switching to tty doesn't work.

I'm seeing the same thing.

I see this as well. Actually I've had this problem for some time but never got around to submitting a bug report. I'm on Arch linux and have two displays, which I mention because I've noticed this seems to have been a factor in previous issues with kscreenlocker.

for those experiencing the issue:
1) please provide output of "qdbus org.kde.KWin /KWin supportInformation" while the screen is locked
2) please try to gdb into kscreenlocker_greet and get a backtrace, so that we see where it loops.

Created attachment 94863 [details]
qdbus org.kde.KWin /KWin supportInformation

output from qdbus org.kde.KWin /KWin supportInformation

output from gdb: (I'm not sure it this is usable, it looks like it is in the same loop)
(gdb) where
#0  0x00007f0ea6b8b18d in poll () from /usr/lib/libc.so.6
#1  0x00007f0e9f12cc7c in ?? () from /usr/lib/libglib-2.0.so.0
#2  0x00007f0e9f12cd8c in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#3  0x00007f0ea74c323f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#4  0x00007f0ea746a26a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#5  0x00007f0ea747220c in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5
#6  0x000000000040d0d5 in main ()
-------- next try ----
#0  0x00007f0ea6b8b18d in poll () from /usr/lib/libc.so.6
#1  0x00007f0e9f12cc7c in ?? () from /usr/lib/libglib-2.0.so.0
#2  0x00007f0e9f12cd8c in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#3  0x00007f0ea74c323f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#4  0x00007f0ea746a26a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#5  0x00007f0ea747220c in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5
#6  0x000000000040d0d5 in main ()
-------- next try ----
#0  0x00007f0ea172407f in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
#1  0x00007f0e922bdcab in ?? () from /usr/lib/xorg/modules/dri/swrast_dri.so
#2  0x00007f0e922ca9fb in ?? () from /usr/lib/xorg/modules/dri/swrast_dri.so
#3  0x00007f0e922cb413 in ?? () from /usr/lib/xorg/modules/dri/swrast_dri.so
#4  0x00007f0e91e883f4 in ?? () from /usr/lib/xorg/modules/dri/swrast_dri.so
#5  0x00007f0e9fe91437 in ?? () from /usr/lib/libGL.so.1
#6  0x00007f0e93745462 in ?? () from /usr/lib/qt/plugins/xcbglintegrations/libqxcb-glx-integration.so
#7  0x00007f0ea7a01b16 in QOpenGLContext::swapBuffers(QSurface*) () from /usr/lib/libQt5Gui.so.5
#8  0x00007f0ea9888f3e in ?? () from /usr/lib/libQt5Quick.so.5
#9  0x00007f0ea9889cd1 in ?? () from /usr/lib/libQt5Quick.so.5
#10 0x00007f0ea746c769 in QCoreApplication::notify(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5
#11 0x00007f0ea746c89b in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5
#12 0x00007f0ea74c205d in QTimerInfoList::activateTimers() () from /usr/lib/libQt5Core.so.5
#13 0x00007f0ea74c2599 in ?? () from /usr/lib/libQt5Core.so.5
#14 0x00007f0e9f12c9fd in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#15 0x00007f0e9f12cce0 in ?? () from /usr/lib/libglib-2.0.so.0
#16 0x00007f0e9f12cd8c in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#17 0x00007f0ea74c323f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#18 0x00007f0ea746a26a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#19 0x00007f0ea747220c in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5
#20 0x000000000040d0d5 in main ()
-------- next try ----
#0  0x00007f0ea6b8b18d in poll () from /usr/lib/libc.so.6
#1  0x00007f0e9f12cc7c in ?? () from /usr/lib/libglib-2.0.so.0
#2  0x00007f0e9f12cd8c in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#3  0x00007f0ea74c323f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#4  0x00007f0ea746a26a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#5  0x00007f0ea747220c in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5
#6  0x000000000040d0d5 in main ()

@Jaroslav: thanks! Given your output you don't have a graphics driver installed and it falls back to software rasterizer. That could explain the problem. I highly recommend to install proper drivers.

@Martin: hmm, strange, because I should have drivers (nvidia)
Where I can find I'm using software rasterizer?

Ah, I see it in the traces. Anyway, when I run glxinfo, then I see I have direct rendering (but I already reverted back to kde-workspace.)
Is possible to Qt5 have an bug or something and selects wrong driver?

 name of display: :0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
    GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, 
    GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, 
    GLX_SGIX_pbuffer, GLX_SGI_make_current_read
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
...
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.7, 128 bits)
OpenGL version string: 3.0 Mesa 11.0.2
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:

(In reply to Jaroslav Safka from comment #12)
> Ah, I see it in the traces. Anyway, when I run glxinfo, then I see I have
> direct rendering (but I already reverted back to kde-workspace.)

Since a decade or so the information "direct rendering" is useless to identify whether drivers work.

> OpenGL vendor string: VMware, Inc.
> OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.7, 128 bits)
> OpenGL version string: 3.0 Mesa 11.0.2

llvmpipe is Mesa's software rasterizer. As you can see it doesn't say NVIDIA.

setting to worksforme as of comment #12.

This makes the screen locker unusable on ARM systems without GPU driver, e.g. Banana Pi.

(In reply to Ralf-Peter Rohbeck from comment #15)
> This makes the screen locker unusable on ARM systems without GPU driver,
> e.g. Banana Pi.

This bug report was about an NVIDIA driver not being installed. That is totally different to ARM systems and a different issue.

As I understood it the resolution is "use a decent GPU."

The resolution for this bug report is: install the Nvidia driver. As I wrote in the previous comment: you have a different issue

Created attachment 105213 [details]
dbus org.kde.KWin /KWin supportInformation

I'm having similar problem with nvidia card/drivers.
I have multi user setup where one user has locked screen and other one is using the system, the user with locked screen is running kscreenlocker_greet @ 100% cpu

I also have this problem on a multiuser setup. At the moment there are 4 login sessions on different virtual screens. Two of the nonactive ones behave nicely, but on of them is spinning one core at 100%. This with Nvidia drivers. So the issues is NOT resolved...

Here an extract of an strace of the bad screenlocker: 
[pid 12126] futex(0x5651d612b36c, FUTEX_WAIT_PRIVATE, 459831, NULL <unfinished ...>
[pid 12251] <... restart_syscall resumed> ) = -1 ETIMEDOUT (Connection timed out)
[pid 12251] futex(0x7f0508252f98, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 12251] clock_gettime(CLOCK_MONOTONIC, {tv_sec=1798396, tv_nsec=523409219}) = 0
[pid 12251] clock_gettime(CLOCK_MONOTONIC, {tv_sec=1798396, tv_nsec=523437825}) = 0
[pid 12251] futex(0x7f0500000a64, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 13051589, {tv_sec=1494750748, tv_nsec=585611000}, 0xffffffff <unfinished ...>
[pid 12241] <... restart_syscall resumed> ) = -1 ETIMEDOUT (Connection timed out)
[pid 12253] <... restart_syscall resumed> ) = -1 ETIMEDOUT (Connection timed out)
[pid 12241] futex(0x5651d5c31338, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
[pid 12253] futex(0x7f0504253398, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
[pid 12241] <... futex resumed> )       = 0
[pid 12253] <... futex resumed> )       = 0
[pid 12241] clock_gettime(CLOCK_MONOTONIC,  <unfinished ...>
[pid 12253] clock_gettime(CLOCK_MONOTONIC,  <unfinished ...>
[pid 12241] <... clock_gettime resumed> {tv_sec=1798396, tv_nsec=531774677}) = 0
[pid 12253] <... clock_gettime resumed> {tv_sec=1798396, tv_nsec=531786416}) = 0
[pid 12241] clock_gettime(CLOCK_MONOTONIC,  <unfinished ...>
[pid 12253] clock_gettime(CLOCK_MONOTONIC,  <unfinished ...>
[pid 12241] <... clock_gettime resumed> {tv_sec=1798396, tv_nsec=531817216}) = 0
[pid 12253] <... clock_gettime resumed> {tv_sec=1798396, tv_nsec=531842134}) = 0
[pid 12241] futex(0x7f0520000a64, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 13714495, {tv_sec=1494750748, tv_nsec=594006000}, 0xffffffff <unfinished ...>
[pid 12253] futex(0x7f04f8000a64, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 13712545, {tv_sec=1494750748, tv_nsec=594021000}, 0xffffffff <unfinished ...>
[pid 12251] <... futex resumed> )       = -1 ETIMEDOUT (Connection timed out)
[pid 12251] futex(0x7f0508252f98, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 12251] clock_gettime(CLOCK_MONOTONIC, {tv_sec=1798396, tv_nsec=623569800}) = 0
[pid 12251] clock_gettime(CLOCK_MONOTONIC, {tv_sec=1798396, tv_nsec=623596748}) = 0
[pid 12251] futex(0x7f0500000a64, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 13051591, {tv_sec=1494750748, tv_nsec=685769000}, 0xffffffff <unfinished ...>
[pid 12241] <... futex resumed> )       = -1 ETIMEDOUT (Connection timed out)
[pid 12253] <... futex resumed> )       = -1 ETIMEDOUT (Connection timed out)
[pid 12241] futex(0x5651d5c31338, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
[pid 12253] futex(0x7f0504253398, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
[pid 12241] <... futex resumed> )       = 0
[pid 12253] <... futex resumed> )       = 0
[pid 12241] clock_gettime(CLOCK_MONOTONIC,  <unfinished ...>
[pid 12253] clock_gettime(CLOCK_MONOTONIC,  <unfinished ...>
[pid 12241] <... clock_gettime resumed> {tv_sec=1798396, tv_nsec=631951238}) = 0
[pid 12253] <... clock_gettime resumed> {tv_sec=1798396, tv_nsec=631957635}) = 0
[pid 12241] clock_gettime(CLOCK_MONOTONIC,  <unfinished ...>
[pid 12253] clock_gettime(CLOCK_MONOTONIC,  <unfinished ...>
[pid 12241] <... clock_gettime resumed> {tv_sec=1798396, tv_nsec=631981719}) = 0
[pid 12253] <... clock_gettime resumed> {tv_sec=1798396, tv_nsec=631988158}) = 0
[pid 12241] futex(0x7f0520000a64, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 13714497, {tv_sec=1494750748, tv_nsec=694161000}, 0xffffffff <unfinished ...>
[pid 12253] futex(0x7f04f8000a64, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 13712547, {tv_sec=1494750748, tv_nsec=694177000}, 0xffffffff <unfinished ...>
[pid 12251] <... futex resumed> )       = -1 ETIMEDOUT (Connection timed out)

I've also was hit by the same issue - it's definitely linked to NVIDIA drivers. I've been using 384.90 drivers on Debian 9. When I start more than one session, kscreenlocker_greet (5.8.6 as in Debian 9) starts to hog CPU to 100%, using two processes.

Backtrace of one of them looks like this, second one locks inside NVIDIA libs (no debug symbols unfortunately):

#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f7b1312fc6b in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#2  0x00007f7b13ff5758 in QSGThreadedRenderLoop::polishAndSync (this=this@entry=0x55f3e7423e00, w=<optimized out>, inExpose=inExpose@entry=false) at scenegraph/qsgthreadedrenderloop.cpp:1183
#3  0x00007f7b13ff6087 in QSGThreadedRenderLoop::handleUpdateRequest (this=0x55f3e7423e00, window=0x55f3e7428980) at scenegraph/qsgthreadedrenderloop.cpp:1010
#4  0x00007f7b1402e216 in QQuickWindow::event (this=0x55f3e7428980, e=0x7ffca8e8a0b0) at items/qquickwindow.cpp:1527
#5  0x00007f7b132fe87a in QCoreApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x00007f7b132fe9e0 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#7  0x00007f7b1365260e in QWindowPrivate::deliverUpdateRequest() () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#8  0x00007f7b13652b59 in QWindow::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#9  0x00007f7b1402e1b5 in QQuickWindow::event (this=0x55f3e7428980, e=0x7ffca8e8a270) at items/qquickwindow.cpp:1546
#10 0x00007f7b132fe87a in QCoreApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x00007f7b132fe9e0 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#12 0x00007f7b13351fee in QTimerInfoList::activateTimers() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#13 0x00007f7b13352549 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#14 0x00007f7b0f2387f7 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x00007f7b0f238a60 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#16 0x00007f7b0f238b0c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x00007f7b1335304f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#18 0x00007f7b132fc9ca in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#19 0x00007f7b1330513c in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#20 0x000055f3e539ab5a in main (argc=<optimized out>, argv=<optimized out>) at ./greeter/main.cpp:181

I have found some workaround (until NVIDIA fixes their drivers... or Qt will do something):
1) Rename kscreenlocker_greet binary to something like kscreenlocker_greet.bin (on Debian 9 it's located in /usr/lib/x86_64-linux-gnu/libexec/kscreenlocker_greet - it's in package libkscreenlocker5)
2) Create wrapper script named kscreenlocker_greet that runs the kscreenlocker_greet binary but with enforced basic render loop (which does not use threads, thus NVIDIA doesn't lock), make it executable:

#!/bin/bash
QSG_RENDER_LOOP=basic /usr/lib/x86_64-linux-gnu/libexec/kscreenlocker_greet.bin $@

Close all sessions, and check then again. Works for me. :)

As far as I can tell, the bug is still present on Plasma 5.10.5 (Kubuntu 17.10), and at least in my case, it happens with an Intel GPU (Iris Plus Graphics 640, Dell XPS13).
I didn't do much testing, but it seems to happen more likely when I'm using an external monitor connected via the USB-C dongle.

Not sure what other info I should provide, but I'll be happy to do it, if somebody thinks it would be helpful.

I am experiencing this bug on plasma 5.13.5 using intel integrated graphics.
Whenever the screen locks kscreenlocker_greet starts eating cpu with consequent fan spin. This is very annoying and destroys the concept of energy saving. Since I'm not using nvidia graphics I doubt it's related to that specific driver, unless there is more than one bug (if someone thinks this is the case, I'll promptly file another bug).

I'm appending output of "qdbus org.kde.KWin /KWin supportInformation" for my system (a mid 2007 macmini).

Created attachment 114342 [details]
qdbus org.kde.KWin /KWin supportInformation macmini mid 2007

(In reply to Gianni from comment #25)
> Created attachment 114342 [details]
> qdbus org.kde.KWin /KWin supportInformation macmini mid 2007

You are using xrender compositing. This could indicate that your OpenGL drivers are broken. That would explain the high cpu usage.

> You are using xrender compositing. This could indicate that your OpenGL
> drivers are broken. That would explain the high cpu usage.

I am indeed using xrender compositing because my graphic chip (Intel GMA950) doesn't support opengl 2.x (only up to 1.4).
Using xrender compositing gave me good enough performance while using plasma so far, and the bug wasn't there before 5.13 (I am unsure if the problem appeared at a certain version of 5.13, like 5.13.1 or so on).
I take responsibility for not communicating sooner that the problem wasn't present in previous versions of Plasma on my machine.
Since I'm not noticing abnormal performance issues other than the unreasonable cpu spikes during screen lock, I would like to encourage taking into account other possibilities.
I'm currently learning how to use gdb in order to provide useful debug information as asked. I'll post the result as soon as I have had success with it.

Created attachment 114379 [details]
gdb backtrace output of kscreenlocker_greet on intel GMA950

I ran gdb after entering via ssh to the machine and gave the bt command.

I'm sorry but a GPU not providing at least OpenGL 2 does not fulfill the hardware requirements of Plasma. Please consider using different hardware. I'm not able to provide you any alternative from software side - even Lubuntu just announced to no longer support such old hardware (LXQt has the same hardware requirement as Plasma).

You can force OpenGL 2.1 for intel 915+ by enabling ARB_occlusion_query and ARB_fragment_shader in drirc.

Another thing to try is typing  "plasma renderer" into krunner
from there you can select "Rendering backend = software"

Changes will apply after session restart. I would like to hear back on how good the performance is.

(In reply to David Edmundson from comment #31)
> Another thing to try is typing  "plasma renderer" into krunner
> from there you can select "Rendering backend = software"
> 
> Changes will apply after session restart. I would like to hear back on how
> good the performance is.

This is an interesting setting. The performance seems pretty good with better responsiveness and it also "solves" another bug I filed some time ago about sluggish desktop interaction #388808.
Unfortunately this setting breaks something because I can't see the themes preview anymore in system settings -> workspace themes.
Furthermore this doesn't solve the kscreenlocker_greet cpu issue.
I don't know if this is the right place, but I'm interested in knowing what difference there is between setting XRender compositor and setting Rendering backend = software.

(In reply to Christoph Feck from comment #30)
> You can force OpenGL 2.1 for intel 915+ by enabling ARB_occlusion_query and
> ARB_fragment_shader in drirc.

Well, I didn't expect I could do that. Now I'm using OpenGL 2.1, so plasma provides more effects and seems more responsive, except for certain localized areas (like the workspace theme section, that apparently has become slower).
Unfortunately, the kscreenlocker_greet issue is still present, but now that I have a capable opengl 2 graphic chip, I'm appending new qdbus and gdb debug info when using OpenGL 2 compositor.

ps. These were really useful tips anyway, I apreciate that.

Created attachment 114383 [details]
qdbus org.kde.KWin /KWin supportInformation on intel GMA950 with OpenGL 2 compositor

qdbus org.kde.KWin /KWin supportInformation on intel GMA950 with OpenGL 2 compositor

Created attachment 114384 [details]
gdb backtrace output of kscreenlocker_greet on intel GMA950 using OpenGL 2 compositor

gdb backtrace output of kscreenlocker_greet on intel GMA950 using OpenGL 2 compositor

>I don't know if this is the right place, but I'm interested in knowing what difference there is between setting XRender compositor and setting Rendering backend = software.

Compositor settings affect only the window manager. GL clients will still use GL.

This setting affects only the clients (plasmashell / systemsettings / whatever)

There are reasons to mix and match those two.
(unfortunately it was requested my settings for plasma should be hidden)

It seems I forgot to add the one line to support kscreenlocker :/
I shall add that for the next patch release. Sorry.

In the meantime, you can export 
QT_QUICK_BACKEND=software globally and confirm if that fixes it.

>and it also "solves" another bug I filed some time ago about sluggish desktop interaction #388808.

Awesome.



>Unfortunately this setting breaks something because I can't see the themes preview anymore in system settings -> workspace themes.

That was reported and fixed this week.

(In reply to David Edmundson from comment #35)

> Compositor settings affect only the window manager. GL clients will still use GL.
> This setting affects only the clients (plasmashell / systemsettings / whatever)
> There are reasons to mix and match those two.

Thanks for explaining me.

> In the meantime, you can export 
> QT_QUICK_BACKEND=software globally and confirm if that fixes it.

I confirm that setting this env variable fixes the kscreenlocker_greet cpu issue for me!

> >Unfortunately this setting breaks something because I can't see the themes preview anymore in system settings -> workspace themes.
> 
> That was reported and fixed this week.

Nice to hear! I hope to see this in the next bugfix update.

In conclusion if I got this correctly the cpu issue was related to qt quick having bad performance issues (during screen lock) with outdated hardware not providing or providing an inefficient opengl backend. This is solved with setting the "plasma renderer" to "software", but this (until there's the patch you mentioned) doesnt comprehend kscreenlocker (or qtQuick?) so as a temporary workaround I also have to set QT_QUICK_BACKEND=software globally.

Git commit 3f104cbb0a34024dc1aa45538d2ef2403a7a45f0 by David Edmundson.
Committed on 09/08/2018 at 23:18.
Pushed by davidedmundson into branch 'master'.

Load QtQuickSettings for software rendering

We had support for falling back on errors yet somehow
the initial basic loading was missing.

Summary: BUG: 347772

Test Plan: Compiles

Reviewers: #plasma, broulik

Reviewed By: #plasma, broulik

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D14708

M  +3    -0    greeter/main.cpp

https://commits.kde.org/kscreenlocker/3f104cbb0a34024dc1aa45538d2ef2403a7a45f0

Git commit c25251a7eb051c7e6914e188f39773d654cb7358 by David Edmundson.
Committed on 20/08/2018 at 08:50.
Pushed by davidedmundson into branch 'Plasma/5.12'.

Load QtQuickSettings for software rendering

We had support for falling back on errors yet somehow
the initial basic loading was missing.

Summary: BUG: 347772

Test Plan: Compiles

Reviewers: #plasma, broulik

Reviewed By: #plasma, broulik

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D14708

M  +3    -0    greeter/main.cpp

https://commits.kde.org/kscreenlocker/c25251a7eb051c7e6914e188f39773d654cb7358

I still see this issue, completely reproducible. We are always logged in with multiple users on the same console, switching from one account to another with KDE's "Switch User" facility.

1) when user A locks the screen, then using the 'Switch User' button on the locked screen, CPU is normal (~1%). 

2) when user A selects the 'Switch User' from the K-menu, then I see
/usr/lib/x86_64-linux-gnu/libexec/kscreenlocker_greet --immediateLock --graceTime 5000 --ksldfd 36

shooting up 100%+ on 2 cores (htop reports values from 98% to 133% sometimes). Now if 3 users are logged in and 2 have switched accounts this way (the most convenient actually), then 4+ cores are being maxed out, rendering the machine unusable, and then less experienced users simply reboot it with the reset button (sometimes by pressing it for 25 seconds, needing journal replays on disk paritions)



My rig:
Kubuntu 18.04
libkscreenlocker5:amd64  5.12.8-0ubuntu0.1

The same issue, eats ~80% of one CPU core resources. There is no renedring, no fancy opengl "screen saver" etc.
10218 zzz   20   0 1153924 249660 102728 S  20,7   3,1  17:02.36 kscreenlocker_g

/usr/lib64/libexec/kscreenlocker_greet --immediateLock --graceTime 5000 --ksldfd 33

kde-plasma/kscreenlocker-5.16.4, Gentoo.

I am seeing this while running plasma under Xvnc. kscreenlocker_greet is wasting around 25% of a core.

Same here using FC30.

Version: kscreenlocker-5.15.5-1.fc30.x86_64

Connected to it with strace and the time seems to be spent in a poll loop with very short timeout.

[pid 24752] poll([{fd=5, events=POLLIN}, {fd=10, events=POLLIN}, {fd=17, events=POLLIN}, {fd=18, events=POLLPRI}, {fd=19, events=POLLIN}, {fd=21, events=POLLIN}, {fd=24, events=POLLIN}, {fd=26, events=POLLIN}], 8, 5) = 0 (Timeout)

*** Bug 418764 has been marked as a duplicate of this bug. ***

*** Bug 418773 has been marked as a duplicate of this bug. ***

5.18.4.1 is still broken

As far as I know kscreenlocker auto restarts when killed and after that starts working properly (the screen will still be locked but at least it's possible to login).

Does anyone have a systemd system resume hook auto-kill kscreenlocker?

Maybe something like this (not tested)

[Unit]
Description=KScreenLocker resume killer
After=systemd-suspend.service
After=systemd-hibernate.service

[Service]
Type=oneshot
ExecStart=/bin/killall -9 "kscreenlocker_greet"

[Install]
RequiredBy=systemd-suspend.service
RequiredBy=systemd-hibernate.service

Created attachment 127682 [details]
qdbus org.kde.KWin /KWin supportInformation

For me the problem is not about CPU but black screen after system resume from stand-by. Happens randomly. I tried to type my password blindly but the screen wasn't unlocked so I believe the thread accepting input got stuck.

after some testing QSG_RENDER_LOOP=basic seems to be the perfect workaround.

Switching to the basic render loop as per #c22 also fixed it for me, thanks! Now my Raspberry Pi is no longer overheating. :)

I tried to do same QSG_RENDER_LOOP=basic trick with kscreenlocker-5.18.5 but after 2 days of testing it seems it doesn't work anymore.

stack trace looks pretty much the same, it stucks somewhere in nvidia libraries on creating textures.

This appears to be me on Ubuntu 20.04.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04 LTS
Release:        20.04
Codename:       focal
$ lspci | grep NVIDIA
01:00.0 VGA compatible controller: NVIDIA Corporation G86 [Quadro NVS 290] (rev a1)
$ 

top - 20:46:46 up 2 days, 18 min,  3 users,  load average: 2.10, 2.60, 2.69
Tasks: 269 total,   3 running, 266 sleeping,   0 stopped,   0 zombie
%Cpu(s): 27.3 us, 31.8 sy,  0.0 ni, 39.4 id,  0.0 wa,  0.0 hi,  1.5 si,  0.0 st
MiB Mem :  11913.5 total,   3063.1 free,   3806.3 used,   5044.1 buff/cache
MiB Swap:   9172.0 total,   9150.0 free,     22.0 used.   7474.3 avail Mem 

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                                                                 
   3164 --------  20   0 1128104 169672  55640 S 200.0   1.4   5675:10 kscreenlocker_g

I don't know if it's related or not. but with recent updates (kscreen/locker 5.19.3, nvidia drivers 450.57) ctrl+alt+L does not show lock screen anymore, instead it makes everything untouchable but still visible.

But as always killing kscreenlocker_greet helps (after entering password everything works well).

(In reply to Sergey from comment #51)
> I don't know if it's related or not. but with recent updates (kscreen/locker
> 5.19.3, nvidia drivers 450.57) ctrl+alt+L does not show lock screen anymore,
> instead it makes everything untouchable but still visible.
> 
> But as always killing kscreenlocker_greet helps (after entering password
> everything works well).

I have same case here:
Opensuse Tumbleweed
kde 5.19.3
Nvidia drivers 450.57

My temporaly workaround is Ctl+Alt-F1, open a terminal and 

sudo  loginctl unlock-sessions

Seeing this on Debian 10 with 5.14.5, and only kscreenlock_greet not plasmashell or any other components (and wondering how is this even still a thing)

nb: I see this on many hosts not just ones using nvidia drivers.  To be honest I don't believe the earlier assertion that this original bug is specific to nvidia is accurate and has likely been a red herring.  Surely kscreenlock_greet is doing something wrong in order for this to affect so many systems across so many versions for so many years - meanwhile plasmashell using the same Qt5 and gfx drivers is fine ?

It may not still even be a thing; Plasma 5.14.5 is almost two years old at this point so there's a chance that it's been fixed in a newer version which you don't have. You could switch to Debian Testing to give it a try.

(In reply to Nate Graham from comment #55)
> It may not still even be a thing; Plasma 5.14.5 is almost two years old at
> this point so there's a chance that it's been fixed in a newer version which
> you don't have. You could switch to Debian Testing to give it a try.

Good point, I'll try that.  I just recall the phoronix article saying this was 'fixed' in 5.14's release

Problem still exists in plasma 5.19.4

(In reply to Nate Graham from comment #55)
> It may not still even be a thing; Plasma 5.14.5 is almost two years old at
> this point so there's a chance that it's been fixed in a newer version which
> you don't have. You could switch to Debian Testing to give it a try.

It is definitely still a thing.  Happening on 5.18.5 on ubuntu 20.04 as well.  In fact it is happening on every single host I have spanning multiple distros and architectures.  This is a very real bug in current kscreenlocker_greet that chews 100% of a core when ever the screen is locked.

I guess if this has been addressed previously we should call it a regression?

What info is needed to diagnose this?

I decided to test on kde neon testing, with libkscreenlocker5 5.19.4+p20.04+git20200818.2051-0 and kscreenlocker_greet appears to actually be behaving here.  There's a separate issue with plasmashell chewing 200% cpu when the systray widget is displayed in the panel.. but kscreenlocker_greet is fine

Definitely still going on... I'm on 5.19.5 and it just happened again...

5+ years and counting :(. I'm happy to provide any logs that are needed or help testing with beta builds etc. let me know.

(In reply to anomaly256 from comment #59)
> There's a separate issue with plasmashell chewing 200%
> cpu when the systray widget is displayed in the panel..

That might be fixed by https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/118.

I can reproduce kscreenlocker_greet taking unreasonable amounts of CPU (but not 100%) when the main area is faded out for basically ever.

(In reply to Fabian Vogt from comment #61)
> I can reproduce kscreenlocker_greet taking unreasonable amounts of CPU (but
> not 100%) when the main area is faded out for basically ever.

Surprisingly this appears to be the password box. Just the redrawing for the blinking cursor seems to be that expensive.

Converting the TextField to use PlasmaComponents3 and "cursorVisible: lockScreenUiVisible" does the trick, at least when it's faded out.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/372

Thanks

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/556

Git commit 45e0a722fb85bb5d1ab8bef92080e934254b13aa by David Edmundson.
Committed on 07/01/2021 at 16:59.
Pushed by davidedmundson into branch 'master'.

[lookandfeel] Avoid rendering invisible contents

An opacity of 0 but still visible still results in nodes in the
scenegraph, which is wasteful.  This is shown in gammaray with some
warnings.

Enabled is also bound to visible as if a text field has focus it still
animates the cursor icon even if inivisble, producing wakeups.
FIXED-IN: 5.21

M  +6    -0    lookandfeel/contents/lockscreen/LockScreenUi.qml

https://invent.kde.org/plasma/plasma-workspace/commit/45e0a722fb85bb5d1ab8bef92080e934254b13aa

Git commit 697b103f5fad5b40b207eabcbce162d6672f5d91 by Nate Graham, on behalf of David Edmundson.
Committed on 07/01/2021 at 17:24.
Pushed by ngraham into branch 'Plasma/5.18'.

[lookandfeel] Avoid rendering invisible contents

An opacity of 0 but still visible still results in nodes in the
scenegraph, which is wasteful.  This is shown in gammaray with some
warnings.

Enabled is also bound to visible as if a text field has focus it still
animates the cursor icon even if inivisble, producing wakeups.
FIXED-IN: 5.21


(cherry picked from commit 45e0a722fb85bb5d1ab8bef92080e934254b13aa)

M  +6    -0    lookandfeel/contents/lockscreen/LockScreenUi.qml

https://invent.kde.org/plasma/plasma-workspace/commit/697b103f5fad5b40b207eabcbce162d6672f5d91

Running Plasma version 5.21.5, KDE Framework 5.82.0, Qt 5.15.2 on Manjaro.

I experience 100% cpu usage when the screen is locked.

Was able to work around it by adding setting QSG_RENDERER_LOOP=basic.

The fix is in 5.22, not 5.21.5.

*** Bug 351463 has been marked as a duplicate of this bug. ***

I am observing a possibly related issue on my new laptop, so this may be caused by the new hardware or a regression.

The issue happens sporadically. When it occurs, the kscreenlocker_greet process consumes 100% CPU. Moving the mouse or starting to type does not show the password prompt on the lock screen. Attempting to kill the kscreenlocker_greet process with SIGTERM has no effect, but sending SIGKILL works and I can proceed with unlocking the session (my avatar on the lock screen had a tiny visual glitch, after performing the kill, it was displayed rectangular instead of being in circle shape).

I tried attaching strace to the process, which worked, but did not produce any output.

Any ideas?

Operating System: Arch Linux
KDE Plasma Version: 5.23.4
KDE Frameworks Version: 5.88.0
Qt Version: 5.15.2
Kernel Version: 5.15.5-arch1-1 (64-bit)
Graphics Platform: X11
Processors: 16 × 11th Gen Intel® Core™ i7-11850H @ 2.50GHz
Memory: 62,5 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics

(In reply to Thilo-Alexander Ginkel from comment #71)
> I tried attaching strace to the process, which worked, but did not produce
> any output.

That sounds more like a hang in the graphics driver or something like that. cat /proc/$(pidof kscreenlocker_greet)/task/*/stack should show.

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!

Hitting this issue (or something very similar) on openSUSE Leap 15.5+Qt  5.15.12 + KDE Frameworks 5.115.0 + Nvidia drivers (nvidia-video-G06-550.67-lp155.20.1.x86_64).

Reproducible: Always
Steps to reproduce:
1. Login as user1
2.  Switch user to user2
3. Observe kscreenlocker_greet and plasmashell processes running as user1 begin to consume 100% CPU.
4. Log off user2 and log back in as user1.
5. High CPU usage disappears.

The workaround from comment 22 does not help.
Output of "qdbus-qt5 org.kde.KWin /KWin supportInformation" is attached.

Created attachment 168152 [details]
qdbus-qt5 org.kde.KWin /KWin supportInformation for comment 75

This is a fairly old bug report and the code has changed a lot since it was reported. There's a very good chance the issue you're experiencing is caused by something else, even if the outward symptoms look and feel the same. Can you please submit a new bug report? Then you can link it to this one using the "See Also" field. Thank you!