Source: qtkeychain Version: 0.17.0-1
Severity: normal Tags: upstream fixed-upstream Hi, Since 0.16.0, isKwalletAvailable() in qtkeychain/keychain_unix.cpp makes a blocking call to org.kde.KWallet.networkWallet with the default 25 second D-Bus timeout. It runs inline on the first keychain job, which is usually the application's GUI thread, so the application freezes until the call times out. kwalletd stops answering application-level D-Bus calls while an unlock dialog is open for any client. That happens at login when the wallet password differs from the login password, because kwallet-pam can't open the wallet. Several autostarted applications can then ask for it at once, and any that probe behind the dialog stall. In plasmashell that freezes the whole shell. With the wallet locked and a dialog opened by another client, I measured: org.freedesktop.DBus.Peer.Ping 0 ms reply org.kde.KWallet.networkWallet 25301 ms NoReply A Qt event loop with a 100 ms heartbeat went 25305 ms between ticks, so that call accounts for the whole freeze. Upstream fixed it by probing with org.freedesktop.DBus.Peer.Ping instead. The QtDBus layer answers Ping, and it still triggers D-Bus activation. commit: https://github.com/frankosterfeld/qtkeychain/commit/007abb86535c6e112d7c0d32ad5372302619b509 PR: https://github.com/frankosterfeld/qtkeychain/pull/304 issue: https://github.com/frankosterfeld/qtkeychain/issues/303 No tagged release has it yet. Once this has a bug number I'll send the commit as a quilt patch against 0.17.0. I reproduced this on Kubuntu 26.10 with kwalletd6 4:26.08.0-0ubuntu1 and libqt6keychain1 0.17.0-1. I haven't run it on Debian. Testing and unstable have the same qtkeychain 0.17.0-1, so I expect the same behaviour, but that comes from the version number, not a test. Debian 13 has 0.15.0, which predates the regression. Full analysis and repro steps are in the Ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/qtkeychain/+bug/2165214 Thomas Moore (realstuffie)
