https://bugs.kde.org/show_bug.cgi?id=522645
--- Comment #3 from David Mužík <[email protected]> --- Thanks for looking into this. I checked both things you asked for. Attaching three files: the busctl --user monitor capture of the frontend<->backend traffic (portal-monitor.log), the xdp-kde debug output with the xdp-kde-* logging categories enabled (xdp-kde-debug.log), and a gdb backtrace of the hung backend taken while it was wedged (xdp-kde-backtrace.txt). 1) Does xdg-desktop-portal call Close on the backend session? Yes, it does — but the backend never processes it. Timeline from busctl monitor (frontend = :1.400, xdg-desktop-portal-kde = :1.410, all times UTC): 16:28:55.808 frontend -> backend: Clipboard.SetSelection (session .../rdportal4059753_session, mime_types text/plain;charset=utf-8, text/plain). Backend immediately emits SelectionOwnerChanged and then SelectionTransfer (asking the client to write the data). The client process exits right after this point, without answering the SelectionTransfer and without Session.Close. 16:28:56.217 last Settings.Read that still received a reply from the backend. 16:28:57.218 next Settings.Read — no reply. From here on the backend main thread never responds to anything again. 16:29:04.988 frontend -> backend: org.freedesktop.impl.portal.Session.Close on the session (cookie 1568). It NEVER receives a method_return (verified: no ReplyCookie=1568 anywhere in the capture). 16:29:18.474 a new client: RemoteDesktop.CreateSession is delivered to the backend — never answered, and it never shows up in the backend's debug log at all. 16:29:48.496 ScreenCast.CreateSession — same, never answered. So the frontend does its part; the backend is already deadlocked ~8 seconds before the Close even arrives. The deadlock is triggered by the SetSelection/SelectionTransfer of the dying client, not by the Close handling itself — the Close simply never gets processed. 2) The "Session closed while owning the clipboard, unsetting clipboard" message never appears. The last lines xdp-kde ever logs are: xdp-kde-clipboard: SetSelection called with parameters: xdp-kde-clipboard: session_handle: "/org/freedesktop/portal/desktop/session/1_415/rdportal4059753_session" xdp-kde-clipboard: options: QMap(("mime_types", QVariant(QStringList, QList("text/plain;charset=utf-8", "text/plain")))) xdp-kde-clipboard: Timeout waiting for data and then nothing, ever (the process keeps running; Peer.Ping still responds). 3) Backtrace of the wedged backend confirms your nested-event-loop + mutex theory. Main thread: #0 syscall #1 QBasicMutex::lockInternal() #2 QRecursiveMutex::tryLock(QDeadlineTimer) #3 ?? libKF6GuiAddons.so.6 #4 ?? xdg-desktop-portal-kde #5-#9 QMetaObject / QCoreApplication::notifyInternal2 #10 QTimerInfoList::activateTimers() #11-#16 nested QEventLoop::exec() <-- inner event loop #17-#18 ?? xdg-desktop-portal-kde #19-#29 outer event loop / QCoreApplication::exec() i.e. the clipboard data wait runs a nested QEventLoop; inside it a timer fires back into kguiaddons, which blocks forever in QRecursiveMutex::tryLock -> QBasicMutex::lockInternal. All other threads are idle (QDBusConnection thread is in its normal poll loop). Apologies for the missing xdp-kde frame symbols — Gentoo build without splitdebug; I can rebuild with debug symbols and retake the trace if that helps. Reproducibility is still 100%: have the client set the clipboard selection through the portal and exit uncleanly while the SelectionTransfer is pending -> the backend deadlocks and every later CreateSession (from any app) hangs until the portal is restarted. -- You are receiving this mail because: You are watching all bug changes.
