Bug 65978 - KWallet-related deadlock involving mouse grabs
Summary: KWallet-related deadlock involving mouse grabs
Status: RESOLVED FIXED
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR critical
Target Milestone: ---
Assignee: George Staikos
URL:
Keywords:
: 66852 71048 72514 72621 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-10-13 19:52 UTC by Maksim Orlovich
Modified: 2005-11-19 10:56 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Maksim Orlovich 2003-10-13 19:52:21 UTC
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)
Comment 1 Dewet Diener 2003-10-24 13:41:24 UTC
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?
Comment 2 George Staikos 2003-11-23 18:39:11 UTC
*** Bug 66852 has been marked as a duplicate of this bug. ***
Comment 3 George Staikos 2003-11-24 00:50:35 UTC
Showstopper
Comment 4 bjrtqqzttgul 2003-11-25 23:11:02 UTC
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
Comment 5 George Staikos 2003-11-27 06:57:35 UTC
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



Comment 6 George Staikos 2003-12-02 20:26:30 UTC
*** Bug 69495 has been marked as a duplicate of this bug. ***
Comment 7 Paul Eggleton 2003-12-29 11:08:21 UTC
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.
Comment 8 George Staikos 2003-12-29 16:13:37 UTC
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.

Comment 9 Lubos Lunak 2004-01-05 19:33:52 UTC
*** Bug 71048 has been marked as a duplicate of this bug. ***
Comment 10 Lubos Lunak 2004-01-13 11:05:11 UTC
*** Bug 72514 has been marked as a duplicate of this bug. ***
Comment 11 Lubos Lunak 2004-01-14 12:57:07 UTC
*** Bug 72621 has been marked as a duplicate of this bug. ***
Comment 12 Oded Arbel 2004-01-14 13:06:40 UTC
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 ?
Comment 13 George Staikos 2004-07-07 22:32:58 UTC
*** Bug 69495 has been marked as a duplicate of this bug. ***
Comment 14 peppelorum 2004-09-11 08:21:34 UTC
This behaviour still exists in 3.3
Comment 15 Gary Shea 2005-04-08 19:33:06 UTC
I'm seeing this behavior exactly as described above in 3.2.3, as distributed in Mandrake 10.1.
Comment 16 Paul Burrowes 2005-05-08 03:31:19 UTC
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.
 
Comment 17 Blindauer Emmanuel 2005-11-19 10:56:46 UTC
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.