Bug 475369 - The plasmashell panel stops visually updating.
Summary: The plasmashell panel stops visually updating.
Status: RESOLVED DUPLICATE of bug 469016
Alias: None
Product: plasmashell
Classification: Plasma
Component: general (show other bugs)
Version: 5.27.8
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-10-08 12:10 UTC by kde.outclass650
Modified: 2023-10-08 12:11 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description kde.outclass650 2023-10-08 12:10:10 UTC
The plasmashell panel stops visually updating. The rendering continues as if stuck in time, so no black squares or anything like that. The applets and hints and previews that show up upon hovering are responsive. The panel continues actually working, just not visually updating. Clicks still work, scrolling on the volume applet as well, etc, and they respect the current status and positions of the applets in the panel, not what is being shown, so if things shifted positions, the interactions match the updated status. Entering edit mode _and_ moving the panel to another side of the screen makes it restart updating. Just moving it a little upwards does not. There is no actual crash happening, even after a long time in this state.

Wayland, NVidia, KDE5, Fedora 38, all up-to-date as of 2023-10-20~. Two virtual desktops. Two screens of different resolutions, one rotated 90 degrees. One is plugged via HDMI (physically connected to the NVidia GPU AFAIK) and another via USB-C->HDMI adapter. Laptop, built-in screen disabled. Bug has been happening for months IIRC, and I think it's only happening with Wayland sessions. Compositing is on (Wayland session) with balanced latency and checked box to reduce it by allowing screen tearing.

Seems to start happening some time after switching virtual desktops, either via the panel applet or shortcuts. Might be related to window previews as I think I witnessed it start exactly after mouse hovering a task switcher entry after going back and forth between virtual desktops. Does not seem to happen until I use another virtual desktop, despite another existing the whole time.

kpipewire_logging: Window not available PipeWireSourceItem_QML_1047(0x55fa59c816a0, parent=0x55fa57b11c20, geometry=0,0 604x294)
kpipewire_logging: Window not available PipeWireSourceItem_QML_1047(0x55fa57614700, parent=0x55fa596290a0, geometry=0,0 604x294)
kpipewire_logging: Window not available PipeWireSourceItem_QML_1047(0x55fa5963d8e0, parent=0x55fa57eb32c0, geometry=0,0 604x294)

is the only thing to come out from the logs.

Diffing backtraces via GDB, between before and after the visual freeze, this is the only substantial difference

Thread 32 (Thread 0x7ff4ebfff6c0 (LWP 95759) "KIO::WorkerThre"):
#0  0x00007ff588d27450 in __GI_ppoll (fds=fds@entry=0x7ff4ebffe928, nfds=nfds@entry=1, timeout=<optimized out>, timeout@entry=0x0, sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:42
#1  0x00007ff58950260d in ppoll (__ss=<optimized out>, __timeout=<optimized out>, __nfds=<optimized out>, __fds=<optimized out>) at kernel/qcore_unix.cpp:129
#2  qt_ppoll (timeout_ts=0x0, nfds=1, fds=0x7ff4ebffe928) at kernel/qcore_unix.cpp:132
#3  qt_ppoll (timeout_ts=0x0, nfds=1, fds=0x7ff4ebffe928) at kernel/qcore_unix.cpp:129
#4  qt_safe_poll(pollfd*, unsigned long, timespec const*) (fds=fds@entry=0x7ff4ebffe928, nfds=nfds@entry=1, timeout_ts=<optimized out>) at kernel/qcore_unix.cpp:155
#5  0x00007ff588b84973 in qt_poll_msecs (nfds=1, timeout=<optimized out>, fds=0x7ff4ebffe928) at ../../include/QtCore/5.15.10/QtCore/private/../../../../../src/corelib/kernel/qcore_unix_p.h:381
#6  QNativeSocketEnginePrivate::nativeSelect(int, bool, bool, bool*, bool*) const (this=this@entry=0x7ff4d8002da0, timeout=<optimized out>, checkRead=checkRead@entry=true, checkWrite=checkWrite@entry=false, selectForRead=0x7ff4ebffea26, selectForWrite=0x7ff4ebffea27) at socket/qnat
ivesocketengine_unix.cpp:1436
#7  0x00007ff588b824d5 in QNativeSocketEngine::waitForReadOrWrite(bool*, bool*, bool, bool, int, bool*) (this=0x7ff4d80025f0, readyToRead=<optimized out>, readyToWrite=<optimized out>, checkRead=true, checkWrite=false, msecs=<optimized out>, timedOut=0x0) at socket/qnativesocketeng
ine.cpp:1120
#8  0x00007ff588b70111 in QAbstractSocket::waitForReadyRead(int) (this=0x7ff4d8002170, msecs=-1) at socket/qabstractsocket.cpp:2293
#9  0x00007ff5889489c2 in KIO::ConnectionBackend::waitForIncomingTask(int) (this=0x7ff4d8001dc0, ms=-1) at /usr/src/debug/kf5-kio-5.109.0-3.fc38.x86_64/src/core/connectionbackend.cpp:155
#10 0x00007ff58897b81a in KIO::Connection::waitForIncomingTask(int) (ms=-1, this=<optimized out>) at /usr/src/debug/kf5-kio-5.109.0-3.fc38.x86_64/src/core/connection.cpp:201
#11 KIO::SlaveBase::dispatchLoop() (this=0x7ff4d8001350) at /usr/src/debug/kf5-kio-5.109.0-3.fc38.x86_64/src/core/slavebase.cpp:332
#12 0x00007ff5889f95e8 in KIO::WorkerThread::run() (this=0x56121604cfe0) at /usr/src/debug/kf5-kio-5.109.0-3.fc38.x86_64/src/core/workerthread.cpp:62
#13 0x00007ff5892f59dd in operator() (__closure=<optimized out>) at thread/qthread_unix.cpp:350
#14 (anonymous namespace)::terminate_on_exception<QThreadPrivate::start(void*)::<lambda()> > (t=<optimized out>) at thread/qthread_unix.cpp:287
#15 QThreadPrivate::start(void*) (arg=0x56121604cfe0) at thread/qthread_unix.cpp:310
#16 0x00007ff588cae947 in start_thread (arg=<optimized out>) at pthread_create.c:444
#17 0x00007ff588d34870 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Adding this just because NVidia is involved and it caught my attention.

Thread 31 (Thread 0x7ff500a376c0 (LWP 95752) "plasmashell"):
#0  0x00007ff588cab219 in __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x56121694dba4) at futex-internal.c:57
#1  __futex_abstimed_wait_common (futex_word=futex_word@entry=0x56121694dba4, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at futex-internal.c:87
#2  0x00007ff588cab29f in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x56121694dba4, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at futex-internal.c:139
#3  0x00007ff588cadbb9 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=<optimized out>, cond=0x56121694db78) at pthread_cond_wait.c:503
#4  ___pthread_cond_wait (cond=0x56121694db78, mutex=<optimized out>) at pthread_cond_wait.c:618
#5  0x00007ff5756b9408 in  () at /lib64/libEGL_nvidia.so.0
#6  0x00007ff5756b9585 in  () at /lib64/libEGL_nvidia.so.0
#7  0x00007ff57569e898 in  () at /lib64/libEGL_nvidia.so.0
#8  0x00007ff57569fc93 in  () at /lib64/libEGL_nvidia.so.0
#9  0x00007ff575649354 in  () at /lib64/libEGL_nvidia.so.0
#10 0x00007ff575a4a9c1 in damage_thread (args=0x56121694a4b0) at ../src/wayland-eglsurface.c:269
#11 0x00007ff588cae947 in start_thread (arg=<optimized out>) at pthread_create.c:444
#12 0x00007ff588d34870 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

~/.profile includes the following, and I think only the first line is really useful so that NVidia GPU is used, the rest IIRC was just debugging attempts.

export KWIN_DRM_DEVICES=/dev/dri/card1:/dev/dri/card0
# export KWIN_DRM_DEVICES=/dev/dri/card1
export KWIN_DRM_USE_EGL_STREAMS=1
export KWIN_DRM_USE_EGLDEVICE=1
export KWIN_OPENGL_INTERFACE=egl
Comment 1 kde.outclass650 2023-10-08 12:11:27 UTC

*** This bug has been marked as a duplicate of bug 469016 ***