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