[plasmashell] [Bug 347772] New: kscreenlocker_greet using 100% cpu on plasma 5

[l***@gmail.com]

https://bugs.kde.org/show_bug.cgi?id=347772

Bug ID: 347772
Summary: kscreenlocker_greet using 100% cpu on plasma 5
Product: plasmashell
Version: 5.3.0
Platform: Ubuntu Packages
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: ***@davidedmundson.co.uk
Reporter: ***@gmail.com
CC: ***@gmail.com, plasma-***@kde.org

Upon locking my screen, the kscreenlocker_greet process CPU usage goes to 100%.
Upon running strace on the pid of kscreenlocker_greet, I see a ton of
stat("/etc/locatime") and a lot of poll (fd=5, events=POLLING). Then when I
enter my session password, I wait for 5-10 seconds for the screen to actually
unlock.

Reproducible: Always

Steps to Reproduce:
1. Lock screen
2. run top from ssh
3. see kscreenlocker_greet process consuming 100% cpu


Actual Results:
4. Enter password and wait 5-10 seconds

Expected Results:
kscreenlocker_greet should not consume an entire processor upon locking my
screen

[Kai Uwe Broulik]

https://bugs.kde.org/show_bug.cgi?id=347772

Kai Uwe Broulik <***@privat.broulik.de> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@privat.broulik.de

--- Comment #1 from Kai Uwe Broulik <***@privat.broulik.de> ---
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.

[l***@gmail.com]

https://bugs.kde.org/show_bug.cgi?id=347772

--- Comment #2 from ***@gmail.com ---
(In reply to Kai Uwe Broulik from comment #1)

Post by Kai Uwe Broulik
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.

[l***@gmail.com]

https://bugs.kde.org/show_bug.cgi?id=347772

--- Comment #3 from ***@gmail.com ---
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.

[David Edmundson]

https://bugs.kde.org/show_bug.cgi?id=347772

David Edmundson <***@davidedmundson.co.uk> changed:

What |Removed |Added
----------------------------------------------------------------------------
Version|5.3.0 |unspecified
Product|plasmashell |ksmserver
Component|general |lockscreen
Target Milestone|1.0 |---

[n***@gmail.com]

https://bugs.kde.org/show_bug.cgi?id=347772

***@gmail.com changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #4 from ***@gmail.com ---
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.

[Leon Maurer]

https://bugs.kde.org/show_bug.cgi?id=347772

Leon Maurer <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #5 from Leon Maurer <***@gmail.com> ---
I'm seeing the same thing.

[Ista Zahn]

https://bugs.kde.org/show_bug.cgi?id=347772

Ista Zahn <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #6 from Ista Zahn <***@gmail.com> ---
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.

[Martin Gräßlin]

https://bugs.kde.org/show_bug.cgi?id=347772

Martin Gräßlin <***@kde.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@kde.org

--- Comment #7 from Martin Gräßlin <***@kde.org> ---
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.

[Jaroslav Safka]

https://bugs.kde.org/show_bug.cgi?id=347772

Jaroslav Safka <***@seznam.cz> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@seznam.cz

--- Comment #8 from Jaroslav Safka <***@seznam.cz> ---
Created attachment 94863
--> https://bugs.kde.org/attachment.cgi?id=94863&action=edit
qdbus org.kde.KWin /KWin supportInformation

output from qdbus org.kde.KWin /KWin supportInformation

[Jaroslav Safka]

https://bugs.kde.org/show_bug.cgi?id=347772

--- Comment #9 from Jaroslav Safka <***@seznam.cz> ---
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 ()

[Martin Gräßlin]

https://bugs.kde.org/show_bug.cgi?id=347772

--- Comment #10 from Martin Gräßlin <***@kde.org> ---
@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.

[Jaroslav Safka]

https://bugs.kde.org/show_bug.cgi?id=347772

--- Comment #11 from Jaroslav Safka <***@seznam.cz> ---
@Martin: hmm, strange, because I should have drivers (nvidia)
Where I can find I'm using software rasterizer?

[Jaroslav Safka]

https://bugs.kde.org/show_bug.cgi?id=347772

--- Comment #12 from Jaroslav Safka <***@seznam.cz> ---
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:

[Martin Gräßlin]

https://bugs.kde.org/show_bug.cgi?id=347772

--- Comment #13 from Martin Gräßlin <***@kde.org> ---
(In reply to Jaroslav Safka from comment #12)

Post by Jaroslav Safka
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.

Post by Jaroslav Safka
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.

[Martin Gräßlin via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=347772

Martin Gräßlin <***@kde.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Component|lockscreen |general
Product|ksmserver |kscreenlocker

[Martin Gräßlin via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=347772

Martin Gräßlin <***@kde.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |WORKSFORME

--- Comment #14 from Martin Gräßlin <***@kde.org> ---
setting to worksforme as of comment #12.

[Ralf-Peter Rohbeck]

https://bugs.kde.org/show_bug.cgi?id=347772

Ralf-Peter Rohbeck <***@yahoo.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@yahoo.com

--- Comment #15 from Ralf-Peter Rohbeck <***@yahoo.com> ---
This makes the screen locker unusable on ARM systems without GPU driver, e.g.
Banana Pi.

[Martin Gräßlin]

https://bugs.kde.org/show_bug.cgi?id=347772

--- Comment #16 from Martin Gräßlin <***@kde.org> ---
(In reply to Ralf-Peter Rohbeck from comment #15)

Post by Ralf-Peter Rohbeck
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.

[Ralf-Peter Rohbeck]

https://bugs.kde.org/show_bug.cgi?id=347772

--- Comment #17 from Ralf-Peter Rohbeck <***@yahoo.com> ---
As I understood it the resolution is "use a decent GPU."

[Martin Gräßlin]

https://bugs.kde.org/show_bug.cgi?id=347772

--- Comment #18 from Martin Gräßlin <***@kde.org> ---
The resolution for this bug report is: install the Nvidia driver. As I wrote in
the previous comment: you have a different issue

[b***@kde.org]

https://bugs.kde.org/show_bug.cgi?id=347772

***@gj.ee changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gj.ee

--- Comment #19 from ***@gj.ee ---
Created attachment 105213
--> https://bugs.kde.org/attachment.cgi?id=105213&action=edit
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

[b***@kde.org]

https://bugs.kde.org/show_bug.cgi?id=347772

***@newtech.fi changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@newtech.fi

--- Comment #20 from ***@newtech.fi ---
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...

[b***@kde.org]

https://bugs.kde.org/show_bug.cgi?id=347772

--- Comment #21 from ***@newtech.fi ---
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)

[Jakub Krajewski]

https://bugs.kde.org/show_bug.cgi?id=347772

Jakub Krajewski <***@krajewski.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@krajewski.org

--- Comment #22 from Jakub Krajewski <***@krajewski.org> ---
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=***@entry=0x55f3e7423e00, w=<optimized out>,
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. :)

[Cyril Chaboisseau]

https://bugs.kde.org/show_bug.cgi?id=347772

Cyril Chaboisseau <***@bigfoot.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@bigfoot.com

[Stefano Forli]

https://bugs.kde.org/show_bug.cgi?id=347772

Stefano Forli <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com
Resolution|WORKSFORME |---
Status|RESOLVED |UNCONFIRMED

--- Comment #23 from Stefano Forli <***@gmail.com> ---
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.

[Gianni]

https://bugs.kde.org/show_bug.cgi?id=347772

Gianni <***@hotmail.it> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@hotmail.it

--- Comment #24 from Gianni <***@hotmail.it> ---
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).

[Gianni]

https://bugs.kde.org/show_bug.cgi?id=347772

--- Comment #25 from Gianni <***@hotmail.it> ---
Created attachment 114342
--> https://bugs.kde.org/attachment.cgi?id=114342&action=edit
qdbus org.kde.KWin /KWin supportInformation macmini mid 2007

[Martin Flöser]

https://bugs.kde.org/show_bug.cgi?id=347772

--- Comment #26 from Martin Flöser <***@kde.org> ---
(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.

[Gianni]

https://bugs.kde.org/show_bug.cgi?id=347772

Post by Martin Flöser
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.

[Gianni]

https://bugs.kde.org/show_bug.cgi?id=347772

--- Comment #28 from Gianni <***@hotmail.it> ---
Created attachment 114379
--> https://bugs.kde.org/attachment.cgi?id=114379&action=edit
gdb backtrace output of kscreenlocker_greet on intel GMA950

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

[Martin Flöser]

https://bugs.kde.org/show_bug.cgi?id=347772

--- Comment #29 from Martin Flöser <***@kde.org> ---
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).

[Christoph Feck]

https://bugs.kde.org/show_bug.cgi?id=347772

--- Comment #30 from Christoph Feck <***@kde.org> ---
You can force OpenGL 2.1 for intel 915+ by enabling ARB_occlusion_query and
ARB_fragment_shader in drirc.

[David Edmundson]

https://bugs.kde.org/show_bug.cgi?id=347772

--- Comment #31 from David Edmundson <***@davidedmundson.co.uk> ---
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.

[Gianni]

https://bugs.kde.org/show_bug.cgi?id=347772

--- Comment #32 from Gianni <***@hotmail.it> ---
(In reply to David Edmundson from comment #31)

Post by David Edmundson
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)

Post by David Edmundson
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.

[Gianni]

https://bugs.kde.org/show_bug.cgi?id=347772

Gianni <***@hotmail.it> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #114342|0 |1
is obsolete| |

--- Comment #33 from Gianni <***@hotmail.it> ---
Created attachment 114383
--> https://bugs.kde.org/attachment.cgi?id=114383&action=edit
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

[Gianni]

https://bugs.kde.org/show_bug.cgi?id=347772

--- Comment #34 from Gianni <***@hotmail.it> ---
Created attachment 114384
--> https://bugs.kde.org/attachment.cgi?id=114384&action=edit
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

[Gianni]

https://bugs.kde.org/show_bug.cgi?id=347772

Gianni <***@hotmail.it> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #114379|0 |1
is obsolete| |

[David Edmundson]

https://bugs.kde.org/show_bug.cgi?id=347772

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.

[Gianni]

https://bugs.kde.org/show_bug.cgi?id=347772

--- Comment #36 from Gianni <***@hotmail.it> ---
(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.

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=347772

Nate Graham <***@kde.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@kde.org

[David Edmundson]

https://bugs.kde.org/show_bug.cgi?id=347772

David Edmundson <***@davidedmundson.co.uk> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
Latest Commit| |https://commits.kde.org/ksc
| |reenlocker/3f104cbb0a34024d
| |c1aa45538d2ef2403a7a45f0

--- Comment #37 from David Edmundson <***@davidedmundson.co.uk> ---
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

[Jaroslav Safka]

https://bugs.kde.org/show_bug.cgi?id=347772

Jaroslav Safka <***@seznam.cz> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC|***@seznam.cz |

[David Edmundson]

https://bugs.kde.org/show_bug.cgi?id=347772

David Edmundson <***@davidedmundson.co.uk> changed:

What |Removed |Added
----------------------------------------------------------------------------
Latest Commit|https://commits.kde.org/ksc |https://commits.kde.org/ksc
|reenlocker/3f104cbb0a34024d |reenlocker/c25251a7eb051c7e
|c1aa45538d2ef2403a7a45f0 |6914e188f39773d654cb7358

--- Comment #38 from David Edmundson <***@davidedmundson.co.uk> ---
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

[b***@kde.org]

https://bugs.kde.org/show_bug.cgi?id=347772

***@gmail.com changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=347772

Nate Graham <***@kde.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Version Fixed In| |5.12.7