Bug 140667 - KMail freezes and hogs CPU when failed IMAP authentication is canceled
Summary: KMail freezes and hogs CPU when failed IMAP authentication is canceled
Status: RESOLVED WAITINGFORINFO
Alias: None
Product: kmail
Classification: Applications
Component: IMAP (show other bugs)
Version: 1.9.5
Platform: Fedora RPMs Linux
: NOR normal with 40 votes (vote)
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-01-26 15:06 UTC by Marcelo Sales
Modified: 2010-01-03 00:45 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
2 backtraces of the SAME freeze (5.38 KB, text/plain)
2007-09-26 21:18 UTC, Ian Hubbertz
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marcelo Sales 2007-01-26 15:06:18 UTC
Version:           1.9.5 (using KDE KDE 3.5.5)
Installed from:    Fedora RPMs
OS:                Linux

When IMAP authentication fails, KMail shows the user/password dialog to let you correct the account info if necessary. If you press "Cancel" in this dialog, KMail freezes and starts to consume 85%-95% of CPU until it's killed. If, instead of pressing the "Cancel" button, you try to authenticate again, KMail becomes usable for some seconds until the authentication fails another time and the account info dialog is shown again. This can be repeated indefinitely.
KMail tries to authenticate in the IMAP server even if the "Check mail in initialization" checkbox in accounts configuration is not checked. Because of this behavior and the "Cancel" bug described above, it's impossible to use KMail if there's a problem with a configured IMAP account.
Steps to reproduce the bug:
1. Configure an IMAP account in KMail, but fill in the password field with a wrong value
2. Close KMail
3. Open KMail. The IMAP account authentication will fail and the user/password dialog will be shown. Other KMail windows will be unusable while this modal dialog is shown (which is ok).
4. Try to authenticate again with a wrong password. KMail will become usable for seconds before the authentication fails again.
5. Now click Cancel in the user/password dialog. The dialog goes away, but KMail remains unusable. No widgets in any opened kmail windows respond to mouse clicks. No keyboard shortcut works. Open ksysguard and note that KMail process is using 85%-95% of CPU. It remains like that until you kill the process.

Don't know if this is important, but I usually run KMail in Kontact.
Comment 1 Philip Rodrigues 2007-01-27 00:38:41 UTC
For the purposes of the KDE bugzilla, freezing isn't a crash
Comment 2 Arne Schmitz 2007-02-22 16:09:52 UTC
Yes, I have the same problem. E.g. at this moment my GMX IMAP account is down and hitting Escape/clicking cancel in the password dialog completely freezes KMail. Using KDE 3.5.5 on Debian Testing.
Comment 3 Antonio Batovanja 2007-03-23 01:04:09 UTC
I can confirm this bug using KMail 1.9.5 and 1.9.6. Actually this bug was the reason I've upgraded to 1.9.6...

IMHO, this bug deserves a higher priority
Comment 4 Thomas McGuire 2007-07-15 14:44:05 UTC
See also bug 147851.
Might be the same, but I am not sure.
Comment 5 Ian Hubbertz 2007-09-26 21:12:51 UTC
bug 147851 is not the same. I can confirm bug 147851 for Gentoo.

Furtheremore I can confirm this, much worser, bug on kubuntu.

I'll attach same backtraces made during freeze. Feel free to contact me (ian| on irc.freenode.org) for further information. (Bug is 100% reproducable)
Comment 6 Ian Hubbertz 2007-09-26 21:18:38 UTC
Created attachment 21697 [details]
2 backtraces of the SAME freeze

First full backtrace, then a new backtraces of the topmost 22 functions after
"continue"ing the program for some seconds.
Comment 7 Ian Hubbertz 2007-09-26 21:22:50 UTC
*** This bug has been confirmed by popular vote. ***
Comment 8 Ian Hubbertz 2007-09-26 21:24:54 UTC
I made some more backtraces, it seems that KMFolderImap::checkValidity() is stuck in an endless loop.
Comment 9 Ian Hubbertz 2007-09-27 00:41:10 UTC
Sorry, the loop is in a higher level: It's QObject::activate_signal() which runs in loop. I set a breakpoint inside activate_signal() (based on the return adress on the stack) and tried to step to an even higher level - this is not possible.
Comment 10 Björn Ruberg 2010-01-03 00:45:55 UTC
Haven't encountered this problem in KDE 4.2+ . Has anyone else?