Version: (using KDE KDE 3.4.0) Installed from: Compiled From Sources Compiler: gcc version 3.3.4 OS: Linux I can easily reproduce a deadlock with KWallet and Konqueror which requires to kill the X server completely as one cannot start/close application with the mouse or use the keyboard. This happens because I have set kppp to execute a command (check mail with KMail) after a connection, so the KWallet dialog requested by KMail appears automatically after the ppp connection is set up. If at the time the KWallet dialog appears I type in the Konqueror Location entry and the autocompletion drop-down list appears the deadlock happens and I cannot do anything, but kill the X server, login ASAP and kill the pppd process, otherwise my phone bill keeps going up. I find this a severe bug. Andras
On Monday 04 April 2005 02:46, Mantia Andras wrote: > I can easily reproduce a deadlock with KWallet and Konqueror which requires > to kill the X server completely as one cannot start/close application with > the mouse or use the keyboard. This happens because I have set kppp to > execute a command (check mail with KMail) after a connection, so the > KWallet dialog requested by KMail appears automatically after the ppp > connection is set up. If at the time the KWallet dialog appears I type in > the Konqueror Location entry and the autocompletion drop-down list appears > the deadlock happens and I cannot do anything, but kill the X server, login > ASAP and kill the pppd process, otherwise my phone bill keeps going up. > > I find this a severe bug. Only happens with KMail? If so, this is due to the synchronous interface blocking kded. Konqueror grabs the display to pop up the dialog, and in that it does a DCOP call to kded to get favicons which also blocks behind the KWallet call. For sure it's a deadlock. Not much I know of that can be done on the KWallet side for this. There is the asynchronous interface which should fix the problem though.
On Monday 04 April 2005 17:38, George Staikos wrote: > Only happens with KMail? I don't know. How can I test if it happens with other app as well? > If so, this is due to the synchronous > interface blocking kded. Konqueror grabs the display to pop up the > dialog, and in that it does a DCOP call to kded to get favicons which > also blocks behind the KWallet call. For sure it's a deadlock. Not > much I know of that can be done on the KWallet side for this. There > is the asynchronous interface which should fix the problem though. But this means that the synchronous interface is really dangerous and should be probably deprecated for KDE 4, isn't it? Andras
On Monday 04 April 2005 11:29, Mantia Andras wrote: > > Only happens with KMail? > > I don't know. How can I test if it happens with other app as well? Have KHTML blocking on it and trigger the completion combo in another konqi window. > > If so, this is due to the synchronous > > interface blocking kded. Konqueror grabs the display to pop up the > > dialog, and in that it does a DCOP call to kded to get favicons which > > also blocks behind the KWallet call. For sure it's a deadlock. Not > > much I know of that can be done on the KWallet side for this. There > > is the asynchronous interface which should fix the problem though. > > But this means that the synchronous interface is really dangerous and > should be probably deprecated for KDE 4, isn't it? It's necessary in some cases, but yes, apps should use the asynchronous interface. I tell everyone who uses KWallet to do that, but no-one does because it's much more difficult to implement.
On Monday 04 April 2005 19:03, George Staikos wrote: >
On Friday 08 April 2005 04:27, Mantia Andras wrote: > But this means that every app using the synchronous interface will have > the same bug and can cause a complete lockup of the UI. Can't this be > avoided in kwallet or kded? Not really. This is why I told people to use the async interface. The synchronous interface is only for apps that absolutely can't use an async interface.
Hello, this happened to me some times with KMail as well as with Konqueror. Last time today. I completely locked X here too. I stopped the Konqueror and KDE processes but it didn't help only way out was restarting X.org. Using KDE 4:3.4.1-1 on Debian Etch. I will switch to KDE 3.4.2-2 or later as soon as enough of my favorite KDE apps have made the C++ ABI change. Regards, Martin Steigerwald
Dupe of bug 102464
Am Freitag 09 Dezember 2005 15:25 schrieben Sie: [bugs.kde.org quoted mail] Hello Philippe, how is that? Bug 103184 is about Konqueror and KWallet, but 102464 ist about KMail and KWallet... Regards,
>how is that? Both bugs are about desktop lockup occuring due to the following events: kmail calls kwallet and
>how is that? Both bugs are about desktop locking up when the following events happen: 1. kmail calls kwallet and the kwallet dialog pops up 2. user types in konqueror location bar => lockup So the real title should be: desktop lockup because of use synchronous kwallet with kmail and konqueror.
This is still there with KDE 3.5.1 Apps shouldn't be able to lock the whole desktop at all! Have ye not learned from windows 9x?
Of course they shouldn't. But drop-down menus and popup-menus work by grabbing the mouse.
This is _really_ a Dupe of bug 102464
Then let's mark it as a duplicate. ;-) *** This bug has been marked as a duplicate of 102464 ***