| Summary: | Kwalletd locks when 2 applications try to open the same wallet, the second using the D-BUS interface | ||
|---|---|---|---|
| Product: | [Applications] kwalletmanager | Reporter: | Andrei Mihaila <andrei.mihaila> |
| Component: | general | Assignee: | Valentin Rusu <valir> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | adaptee, christo.candiotes, christopherheiny, cognifloyd, craig.magina, daniel.pena.arteaga, dietrichmathias, dima, eArquilla, frederic.coiffier, getaceres, gree, joseph.2011, juergen.sauer, juergennagel, julian, kde, leon.maurer, lieven.vanacker, mattm3a, michaelaquilina, null, ochominutosdearco, philipp.woelfel, phlogi1, predder, rdieter, someuniquename, svenstaro, tais.hansen, thanosk, travier, valir, vasyl.demin, xenoterracide, xjakub, yulia.novozhilova |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=317305 | ||
| Latest Commit: | http://commits.kde.org/kdelibs/9027e0620d1f6bb06cbeb00db1072047ccb8ff13 | Version Fixed In: | 4.11.2 |
| Sentry Crash Report: | |||
|
Description
Andrei Mihaila
2010-10-14 21:55:30 UTC
Still there in KDE versions 4.5.3 to 4.6. I wish I could find some time to hunt the problem myself ... Thanks for reading anyway. I stumbled over this bug, too, with Chromium and Kopete locking up kwalletd. Still there in KDE 4.6.4... Additionally, found that after kwalletd is locked the wallet manager shows it as being empty, although it is not (after restarting the daemon all my passwords were there). I also found this problem with KDE SC 4.6.5 in Archlinux. For example, Akonadi IMAP resources will just hang there without being updated, no passwords shown in kwalletmanager, no way to create new wallets, chromium unable to fill password fields if just started, ... If I then kill kwalletd, suddenly the dialogs asking for all password appear, just like without using kwallet, and everything seems to be fixed until next kwallet hang. Same problem with Kopete and Chromium, KDE 4.7.1 I can confirm this bug, also running arch linux. *** This bug has been confirmed by popular vote. *** I can confirm this behavior. I use keychain with ksshaskpass in my bashrc, so I have to -KILL kwalletd every single time I log in to KDE and want to use the console. Same problem with KMess and KRDC. KDE 4.7.3. Same problem in KDE 4.8.1. This looks like an old bug: #123583 I have ksshaskpass and google-chrome cause some kind of race condition hanging ksshaskpass, and kwalletd. Google-chrome continues like nothing happened, except that it doesn't have any saved passwords (as expected with this issue). I'm in gentoo with kde 4.8.3 with a 64 bit kernel. Still present in 4.9.4 .... still using the X or gnome ssh-askpass.... Still present in KDE 4.9.98 (alias 4.10 RC3). And seems much more annoying than previously... This problems hits me while starting KDE (version 4.9.5 on kubuntu 12.10) with both network manager plasma widget and chromium: kwalletd hangs and must be killed to get things working again :-(! Any news on this annoying issues? Is this actually being worked on? It's rather high impact if kwallet is being used to store wireless passwords. I was unable to get online until I figured out what was going on and disabled the wallet. More duplicates: https://bugs.kde.org/show_bug.cgi?id=307731 https://bugs.kde.org/show_bug.cgi?id=259229 *** Bug 307731 has been marked as a duplicate of this bug. *** Getting the same problem upon a session restore. If I have no application asking for a password at startup, then kwalletd works fine. If anything asks for a password during startup/session restore (chrome, chokoq or amarok in my case), then they never get the password and behave abnormally. Kubuntu 12.10 64bits, KDE 4.10. Same problem as here. Ugly Bug. Same problem here, definitely not Gentoo specific (I'm using Fedora). Still present in 4.10.2 In my case, the problem was due to the ownCloud client : if this one isn't restored at the session start, the problem disappears. Frédéric, is it possible that this is because if you don't start the client then there is no more concurrent access to kwallet by two clients? B.t.w. I have the same problem with openSUSE kde 4.10.2 binaries. I "fixed" it by removing the kwallet password. Philipp, in my case, at KDE session startup, many applications are restored at the same time and several of them require a kwallet access : akonadi (2 x POP3, Google resources...), konqueror, amarok, firefox, kopete. I can confirm this issue occurs to me too. In my case wifi gets stuck authenticating and i have to kill and restart kwalletd in order to fix the issue at each startup. I have the same issue only at startup with possibly a race condition as mentioned earlier in this bug report. Running Manjaro 0.8.6 with KDE 4.10.5. Symptoms is that my instant messaging (KDE Telepathy), KMail etc cannot connect being unable to get the passwords from KWallet. Manually opening the wallet in KWallet Manager gives NO entries in the opened wallet. Merely closing the wallet and re-opening does not help. Only workaround for me is to go to Settings->System Settings->Account Details->KDE Wallet then untick "Enable the KDE wallet subsystem" (thereby killing the current instance of KWalletManager and then just ticking it again and Apply it. All works fine then until next reboot. Hope this can point someone in the right direction to resolve this bug. I can confirm the above. Also running on KDE 4.10.5. Only workaround is to set an empty password on the wallet, which completely misses the intended purpose of the application. I cannot understand the lack of attention to this bug, cause it renders the complete DE very insecure. Found race condition in the wallet opening logic. Working on it... The wallet gets locked because of the nested event loops and in the situation where the calling application doesn't have a main window, just like the qdbus call exposed by Andrei. It seems that the password prompt needs some window to attach to and if such a window is given, via the wId open method parameter, then the wallet won't lock. This can be demonstrated by the KWallet Manager application, wich never locks the daemon. In fact, on my system, I never encountered this lock proble. I'll continue the work and try to solve the problem, but it's a hard one. Meanwhile, I suggest a workaround. Your application should wait for the GUI thread to start, then initiate wallet open call taking care to give the main window's ID. @Valentin: First of all thank you very much for investigating this issue. Tried the workaround, don't know if I did it right, but it didn't work - started Amarok and KCalc (could be any 2 KDE apps) then ran in a terminal: -------------- qdbus org.kde.kwalletd /modules/kwalletd org.kde.KWallet.open kdewallet `xwininfo -int -name 'KCalc' | grep 'Window id:' | cut -d' ' -f4` 'Test KCalc' & qdbus org.kde.kwalletd /modules/kwalletd org.kde.KWallet.open kdewallet `xwininfo -int -name 'Amarok' | grep 'Window id:' | cut -d' ' -f4` 'Test Amarok' & -------------- Got roughly similar results to what I wrote in the initial bug report: -------------- Error: org.freedesktop.DBus.Error.NoReply 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. -------------- and a locked kwallet. I wish I could help with the fix but I don't have enough QT knowledge (if at all - I was able to tell that the lock happens when the nested event loop starts but didn't know why). When creating the fix one should bear in mind that there might be cases when a window-less client asks for access to KWallet (for example subversion or git). So for this kind of situation it may be better to have a totally independent thread/process that waits for the wallet to open and then sends the result back to the caller. @Andrei I suppose you didn't wait to enter the password in the open dialog popped by the first command. Isn't it? If you enter the correct password and the wallet opens, kwalletd no longer gets stuck. If I'm correct, then you hit another bug I already planned to fix. That one is about a rush condition when opening wallet. @Valentin Yes, you are correct. That was the issue that I always had at start-up when 2 apps request access to KWallet almost at the same time (and can't make them wait for each other - in which case it would work fine). OK, I look forward to your solution. This is a very annoying bug, thanks you very very much for working on this @Valentin Rusu ! Fixed the bug in kwalletd by kdelibs/kwallet needs also fixing. Please hold on, as I need to commit both in order to prevent regressions. Git commit b0f9053ed8abff4ef973b10842f761422ee17f41 by Valentin Rusu. Committed on 31/08/2013 at 23:28. Pushed by vrusu into branch 'master'. Fix the synchronous-mode wallet open logic The wallet synchronous open requests now use qdbus delayed replies. The execution path now returns to the main event loop instead of a nested event loop. The wallet opening UI logic is correctly handled no longer leading to a frozen kwalletd. Beware that this commit should be used along with the corresponding fix of the kdelibs/kdeui module. Failing to updating kdelibs lead to an aparently similar freeze condition, as kdeui also used an internal event loop, faking synchronous operation when making async kwalletd calls. M +0 -1 kwalletd/CMakeLists.txt M +53 -21 kwalletd/kwalletd.cpp D +0 -46 kwalletd/kwalletopenloop.cpp D +0 -50 kwalletd/kwalletopenloop.h M +1 -0 kwalletd/main.cpp http://commits.kde.org/kde-runtime/b0f9053ed8abff4ef973b10842f761422ee17f41 Git commit f8fea3f01c85eb0d6d479647ac27fe431846a1ae by Valentin Rusu. Committed on 31/08/2013 at 23:16. Pushed by vrusu into branch 'master'. Fix the synchronous-mode wallet open logic The wallet opening logic, for the synchronous mode, had a nested event loops problem, leading to frozen kwalletd. That was because kwalletd wasn't using qdbus delayed replies. kdelibs used asynchronous open methods even for the synchronous mode, coupled with an internal event loop to simulate synchronous mode. This commit removes that internal event loop, as the kwalletd now blocks on synchronous wallet open requests. M +8 -20 kdeui/util/kwallet.cpp http://commits.kde.org/kdelibs/f8fea3f01c85eb0d6d479647ac27fe431846a1ae Please note that this fix consists of two commits, one on kde-runtime and a corresponding on in kdelibs. You should absolutely update and build both modules in order to get the fix. Failing to do that, you get another case of kwallet freeze, in kdelibs this time. Git commit aff38f3cfeca0abb93e899c54f27e382cfa427ac by Valentin Rusu. Committed on 01/09/2013 at 22:15. Pushed by vrusu into branch 'frameworks'. Fix the synchronous-mode wallet open logic The wallet opening logic, for the synchronous mode, had a nested event loops problem, leading to frozen kwalletd. That was because kwalletd wasn't using qdbus delayed replies. kdelibs used asynchronous open methods even for the synchronous mode, coupled with an internal event loop to simulate synchronous mode. This commit removes that internal event loop, as the kwalletd now blocks on synchronous wallet open requests. This commit has the same effect as f8fea3f01c85eb0d on kdelibs 4.11 but cherry-picking won't work because of KF5 source splitting. I just redone it here. M +9 -21 staging/kwallet/src/kwallet.cpp http://commits.kde.org/kdelibs/aff38f3cfeca0abb93e899c54f27e382cfa427ac *** Bug 322925 has been marked as a duplicate of this bug. *** *** Bug 319138 has been marked as a duplicate of this bug. *** *** Bug 317305 has been marked as a duplicate of this bug. *** *** Bug 316624 has been marked as a duplicate of this bug. *** *** Bug 312123 has been marked as a duplicate of this bug. *** *** Bug 308540 has been marked as a duplicate of this bug. *** *** Bug 300991 has been marked as a duplicate of this bug. *** Will this be in 4.11.1? Well, 4.11.1 has already been tagged, so no. It'll be 4.11.2 http://techbase.kde.org/Schedules/KDE4/4.11_Release_Schedule Valentin, I don't see your commits in the KDE/4.11 branch at all yet (only master, frameworks branches). did you mean to backport (or merge) them and forget? *** Bug 259229 has been marked as a duplicate of this bug. *** *** Bug 245869 has been marked as a duplicate of this bug. *** Git commit c5bdc96316e9e5f727085f65fcf8eb059ebf4357 by Valentin Rusu. Committed on 31/08/2013 at 23:28. Pushed by vrusu into branch 'KDE/4.11'. Fix the synchronous-mode wallet open logic The wallet synchronous open requests now use qdbus delayed replies. The execution path now returns to the main event loop instead of a nested event loop. The wallet opening UI logic is correctly handled no longer leading to a frozen kwalletd. Beware that this commit should be used along with the corresponding fix of the kdelibs/kdeui module. Failing to updating kdelibs lead to an aparently similar freeze condition, as kdeui also used an internal event loop, faking synchronous operation when making async kwalletd calls. M +0 -1 kwalletd/CMakeLists.txt M +53 -21 kwalletd/kwalletd.cpp D +0 -46 kwalletd/kwalletopenloop.cpp D +0 -50 kwalletd/kwalletopenloop.h M +1 -0 kwalletd/main.cpp http://commits.kde.org/kde-runtime/c5bdc96316e9e5f727085f65fcf8eb059ebf4357 Git commit 9027e0620d1f6bb06cbeb00db1072047ccb8ff13 by Valentin Rusu. Committed on 31/08/2013 at 23:16. Pushed by vrusu into branch 'KDE/4.11'. Fix the synchronous-mode wallet open logic The wallet opening logic, for the synchronous mode, had a nested event loops problem, leading to frozen kwalletd. That was because kwalletd wasn't using qdbus delayed replies. kdelibs used asynchronous open methods even for the synchronous mode, coupled with an internal event loop to simulate synchronous mode. This commit removes that internal event loop, as the kwalletd now blocks on synchronous wallet open requests. M +8 -20 kdeui/util/kwallet.cpp http://commits.kde.org/kdelibs/9027e0620d1f6bb06cbeb00db1072047ccb8ff13 @Rex: thanks for pointing that out! Thx for fixing this bug Valentin ! Great work, especially as it has some many votes. *** Bug 234939 has been marked as a duplicate of this bug. *** The bug is gone in my KDE 4.11.2 (tested using the 2 commands in my original report). Thank you Valentin! |