https://bugs.kde.org/show_bug.cgi?id=526760
Bug ID: 526760
Summary: plasmashell hangs waiting for KDE Connect notification
D-Bus property when kdeconnectd stops responding
Classification: Applications
Product: kdeconnect
Version First 26.08.1
Reported In:
Platform: Fedora RPMs
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: desktop-application
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Created attachment 196903
--> https://bugs.kde.org/attachment.cgi?id=196903&action=edit
full logs, journals, system info
DESCRIPTION
plasmashell can become completely unresponsive when KDE Connect stops
responding to D-Bus requests. During the hang, applications and KWin continue
working normally, including Alt+Tab, but the Plasma panel, task manager,
desktop widgets and clock all stop updating.
I captured a GDB backtrace while plasmashell was hung. The plasmashell main
thread was blocked in a synchronous D-Bus property request originating from KDE
Connect's NotificationsModel::data() and
OrgKdeKdeconnectDeviceNotificationsNotificationInterface.
After Plasma eventually recovered, kdeconnect-cli -l still failed with:
error: Did not receive a reply. Possible causes include: the remote application
did not send a reply, the message bus security policy blocked the reply, the
reply timeout expired, or the network connection was broken.
kdeconnectd was still running at this point.
Killing and restarting kdeconnectd restored normal operation immediately:
kdeconnect-cli -l then discovered my paired Android phone normally within a few
seconds.
STEPS TO REPRODUCE
I do not currently have a reliable way to deliberately reproduce the initial
kdeconnectd failure.
The problem has occurred intermittently during an otherwise normal Plasma
session with an Android phone paired through KDE Connect and notification
synchronization enabled.
On one occurrence, Plasma remained frozen for approximately an hour. The frozen
Plasma clock showed that the freeze had begun well before I noticed it.
OBSERVED RESULT
The Plasma shell becomes unresponsive:
Panel/task manager does not respond.
Desktop widgets stop updating.
Plasma clock stops updating.
Applications themselves continue running normally.
KWin continues functioning and Alt+Tab still switches between applications.
plasmashell does not crash or restart.
No corresponding kernel/GPU error was recorded.
During the hang, the plasmashell main GUI thread was blocked in a synchronous
D-Bus call through KDE Connect's notification model.
After plasmashell eventually recovered without being restarted, kdeconnectd
remained in an abnormal state: kdeconnect-cli -l timed out instead of returning
the paired device.
Restarting only kdeconnectd restored normal KDE Connect operation.
EXPECTED RESULT
Failure or non-responsiveness of kdeconnectd should not block the plasmashell
GUI thread. KDE Connect requests should fail or time out without making the
Plasma shell unresponsive.
SOFTWARE/ENVIRONMENT
Fedora Kinoite 44
KDE Connect:
kde-connect-26.08.1-1.fc44.x86_64
Plasma:
plasma-workspace-6.7.5-1.fc44.x86_64
Qt:
qt6-qtbase-6.11.2-2.fc44.x86_64
qt6-qtdeclarative-6.11.2-2.fc44.x86_64
KDE Frameworks:
kf6-kcoreaddons-6.30.0-1.fc44.x86_64
Session:
Wayland
Android KDE Connect app:
1.35.17
Notification synchronization was enabled.
ADDITIONAL INFORMATION
While the Plasma hang was occurring, the main plasmashell thread was captured
with GDB using thread apply all bt.
The significant portion of the main-thread backtrace was:
QWaitCondition::wait(QMutex*, QDeadlineTimer)
QDBusPendingCallPrivate::waitForFinished()
QDBusConnectionPrivate::sendWithReply(...)
QDBusConnection::call(...)
QDBusAbstractInterfacePrivate::property(...)
QDBusAbstractInterfaceBase::qt_metacall(...)
QDBusAbstractInterface::qt_metacall(...)
OrgKdeKdeconnectDeviceNotificationsNotificationInterface::qt_metacall(...)
QMetaProperty::read(...)
QObject::property(...)
NotificationsModel::data(QModelIndex const&, int) const
The full plasmashell backtrace is included below.
After Plasma recovered but while kdeconnect-cli -l was still timing out, I also
attached GDB to the running kdeconnectd process.
Its main thread did not appear to be conventionally deadlocked. It was waiting
in the normal Qt/GLib event loop:
ppoll()
g_main_context_iteration()
QEventDispatcherGlib::processEvents(...)
QEventLoop::exec(...)
QCoreApplication::exec()
main()
Its QDBusConnection thread and other worker threads also appeared to be waiting
normally.
Restarting kdeconnectd then restored KDE Connect operation; kdeconnect-cli -l
successfully found the paired phone.
The backtraces were captured without Fedora debuginfod enabled, so some symbols
are unavailable, but the KDE Connect notification functions in the plasmashell
call stack were resolved.
I do not yet know what initially causes kdeconnectd to enter the non-responsive
D-Bus state. The backtrace does show that once this state occurs, a KDE Connect
notification property request can synchronously block the plasmashell GUI
thread.
The kdeconnectd journal also contains evidence of D-Bus communication problems
before I deliberately tested kdeconnect-cli. At 13:30:27, kdeconnectd logged:
Failed to notify "Did not receive a reply. Possible causes include: the remote
application did not send a reply, the message bus security policy blocked the
reply, the reply timeout expired, or the network connection was broken."
At 15:04:10 it subsequently logged:
error activating kdeconnectd: QDBusError("org.freedesktop.DBus.Error.NoReply",
"Did not receive a reply...")
The journal also contains this earlier message at 11:38:21:
QSocketNotifier: Socket notifiers cannot be enabled or disabled from another
thread
I do not know whether that message is related to the later D-Bus failure.
--
You are receiving this mail because:
You are watching all bug changes.
