Version: (using KDE Devel) Installed from: Compiled sources Compiler: gcc-3.3.1 OS: Linux It is possible for kwallet's kded module to induce deadlocks rendering the desktop inoperable as follows: 1. An application sends a kwallet request to kwalletd, which pops up a dialog, suspending much of processing in kded. 2. while the dialog is on-screen, but not responded to, pop-up minicli, and start entering a URL. Auto-completion pop ups, and creates a mouse+keyboard grab that makes the kwallet dialog inaccessible. 3. minicli notices it's a URL, and asks kded's favicons module for an icon, but that is not paying attention due to the dialog, so kdesktop blocks while holding mouse + keyboard grab, so no other app can recieve events, and the grab can't be released until kwalletd gets a response to a dialog. Deadlock. Somewhat less severely, but much easier to hit, Konqueror instances can similarly block when a kwalletd dialog is on the screen, but since they have no grabs, one can get out of the situation by answering the wallet-related popup (however, one can probably trigger the deadlock there too if a popupmenu shows up at the wrong moment)
What got me the first few times is Konqueror seeming to freeze because the wallet dialog wasn't focused at the front. I had to go and fetch it via the taskbar every time, which is kinda annoying. Can't it be made to be on top of everything?
*** Bug 66852 has been marked as a duplicate of this bug. ***
Showstopper
If I go to a passworded-website, then click on bookmarks, and the kwallet dialog opens while the bookmark menu is down, KDE will hang completely (have to ctrl-alt-bksp) I think this is the same problem(?). version: CVS as of 11/25
Subject: kdelibs/kio/misc/kwalletd CVS commit by staikos: rudimentary implementation of dcop transactions for kwallet. still leaves much to be desired, but it seems to help with the deadlock issue anyways. CCMAIL: 65978-done@bugs.kde.org M +132 -27 kwalletd.cpp 1.59 M +10 -1 kwalletd.h 1.33
*** Bug 69495 has been marked as a duplicate of this bug. ***
Not sure if this is supposed to be fixed in KDE 3.1.94, but I think I just experienced this bug: I went to bugs.kde.org, went to log in, started to type my email address which brought up an autocomplete popup, during which time the KDE Wallet password prompt appeared. The desktop was then completely locked. I had to kill kded from another vt before I got control back.
Subject: Re: KWallet-related deadlock involving mouse grabs On Monday 29 December 2003 05:08, Paul Eggleton wrote: > ------- Additional Comments From bluelightning@bluelightning.org > 2003-12-29 11:08 ------- Not sure if this is supposed to be fixed in KDE > 3.1.94, but I think I just experienced this bug: I went to bugs.kde.org, > went to log in, started to type my email address which brought up an > autocomplete popup, during which time the KDE Wallet password prompt > appeared. The desktop was then completely locked. I had to kill kded from > another vt before I got control back. Please try with an updated kde build. this *should* be fixed.
*** Bug 71048 has been marked as a duplicate of this bug. ***
*** Bug 72514 has been marked as a duplicate of this bug. ***
*** Bug 72621 has been marked as a duplicate of this bug. ***
Sorry for the duplicate, I guess I wasn't looking hard enough. Anyway - the fact that there were 3 recent duplicates for this bug suggests to me that it is not fixed, so can someone please change the status of this bug to reflect that ?
This behaviour still exists in 3.3
I'm seeing this behavior exactly as described above in 3.2.3, as distributed in Mandrake 10.1.
I'm getting what appears to be this bug in kde-3.4. For me it is triggered on login if I open a konqueror window and start to enter an url before all programs have loaded. If the history combobox is still open when an app such as KMail that wants to access the wallet starts, the wallet password window will appear and the described deadlock occurs. Killing konq from a vt allows password entry but mouse clicks in the password window (possibly all clicks) are not acknowledged until the password dialog has closed.
This bug is back with kde 3.5 rc1 I use focus follow mouse, steal prevention is set to "low" Having an application which prompt for a password with kwallet, when I'm filling a command with ALT-F2 locks kde.