https://bugs.kde.org/show_bug.cgi?id=475369
Bug ID: 475369
Summary: The plasmashell panel stops visually updating.
Classification: Plasma
Product: plasmashell
Version: 5.27.8
Platform: Fedora RPMs
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: plasma-b...@kde.org
Reporter: kde.outclass...@simplelogin.com
CC: k...@davidedmundson.co.uk
Target Milestone: 1.0
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
--
You are receiving this mail because:
You are watching all bug changes.
