Version: 1.9.5 (using KDE KDE 3.5.5)
Installed from: Fedora RPMs
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.
For the purposes of the KDE bugzilla, freezing isn't a crash
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.
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
See also bug 147851.
Might be the same, but I am not sure.
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)
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.
*** This bug has been confirmed by popular vote. ***
I made some more backtraces, it seems that KMFolderImap::checkValidity() is stuck in an endless loop.
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.
Haven't encountered this problem in KDE 4.2+ . Has anyone else?