Version: 1.9.1 (using KDE KDE 3.5.1) Installed from: Compiled From Sources Compiler: gcc 3.4.5 OS: Linux Kmail's automatic mailcheck hangs at seemingly random intervals. The message "Checking account <xxx> for new mail" persists in the bottom of the window, and the progress bar keeps running. When this happens, kmail will remain partly responsive, but e.g. attempting to start a new check won't do anything. Even shutting down kmail and restarting it won't restore broken mail check functionality. Killing both kio_pop3 processes (I have two mailboxes to check) helps even if kmail is running. I have auto check interval set at 2 minutes for one and 3 minutes for the other mailbox. I have been wondering that maybe the hang might result from mail checks trying to start at the exact same time, but that's only an uneducated guess.
I should add that the mailboxes are on the same server.
Could you try disabling one of the accounts (for testing purposes) to see if the hang still occurs? Or at least disable interval checking for one account.
I set the interval for both accounts to 2 minutes, so they should in no case overlap. No hangs have happened so far. I'll keep my computer running with this setting for maybe a week to see if the problem reappears. (It's been a rare occasion anyhow, so just a day's testing is good for nothing.) If I experience no hangs, I'll again switch to 2 and 3 minutes to test if this is related to intervals overlapping as I suspect. If I experience hangs with equal intervals also, I'll disable auto check for the other mailbox.
There was a hang with both mailboxes set at 2 minutes. So I guess the problem's not with checks overlapping. I've disabled interval checking for the other mailbox, we'll see if I get more hangs with only one.
Yet another hang, now with only one mailbox being checked every 2 minutes. Didn't have to wait for long... Now there was something on screen I've only seen when the hang happened last time (see previous comment). Then I didn't think it was anything special, but now I think it might be related. There was a status text "Folder trash compacted succesfully" visible which wouldn't go away, and the status bar read 100%. Trying to manually check mail worked for the mailbox which _wasn't_ on auto-check, but did nothing for the other. Again, killing kio_pop3 helped, but this time I only had to kill one process (logically enough, as only one mailbox was set on auto).
The hang happened with only one mailbox set on auto-check. Also KMail has been crashing lately (see bug #121384).
This is still happening after upgrading to KDE 3.5.2, compiled with gcc 4.0.3.
It sounds more like a bug with the pop3 kioslave or server than kmail itself. So, if you have compiled the pop3 kioslave with debug info, could you 'attach' to the kio_pop3 process with gdb, and get the backtrace when the hang happens? You can do it by: gdb --pid=<pid of the kio_pop3 process> And then in gdb: interrupt backtrace To resume the process, while still in gdb: detach quit Good luck.
gdb says the same thing about both processes: #0 0xffffe410 in ?? () #1 0xbf871f0c in ?? () #2 0x00000000 in ?? () #3 0xbf871e58 in ?? () #4 0xb715be81 in select () from /lib/libc.so.6 #5 0xb7deeccd in KIO::SlaveBase::dispatchLoop () from /usr/lib/libkio.so.4 #6 0xb7293987 in kdemain () from /usr/lib/kde3/kio_pop3.so #7 0x0804db06 in launch () #8 0x0804e07b in handle_launcher_request () #9 0x0804e471 in handle_requests () #10 0x0804f08b in main () I hope this helps. One thing about this bug hunt bothers me, though: when I attached gdb to the kio_pop3 processes, the very next mailchecks hung, and they also continued after I detached and quit gdb. I tried it twice, same thing both times. When this hang normally happens, only killing the processes helps. Hmm, it's almost as if the usual hangs were caused by gdb running without my knowledge... but I guess that's not possible.
I noticed that a hang had again happened, so I ran gdb on those pids to test what would happen. The first one showed the same as above, but the second one gave this output: #0 0xffffe410 in ?? () #1 0xbf86fa24 in ?? () #2 0x00000000 in ?? () #3 0xbf86fa4c in ?? () #4 0xb715be81 in select () from /lib/libc.so.6 #5 0xb7c0a207 in KSocks::select () from /usr/lib/libkdecore.so.4 #6 0xb7de8028 in KIO::TCPSlaveBase::waitForResponse () from /usr/lib/libkio.so.4 #7 0xb72934fa in POP3Protocol::myReadLine () from /usr/lib/kde3/kio_pop3.so #8 0xb72939f6 in POP3Protocol::getResponse () from /usr/lib/kde3/kio_pop3.so #9 0xb7293da7 in POP3Protocol::command () from /usr/lib/kde3/kio_pop3.so #10 0xb72940c1 in POP3Protocol::closeConnection () from /usr/lib/kde3/kio_pop3.so #11 0xb729702b in POP3Protocol::get () from /usr/lib/kde3/kio_pop3.so #12 0xb7dee67f in KIO::SlaveBase::dispatch () from /usr/lib/libkio.so.4 #13 0xb7deed28 in KIO::SlaveBase::dispatchLoop () from /usr/lib/libkio.so.4 #14 0xb7293987 in kdemain () from /usr/lib/kde3/kio_pop3.so #15 0x0804db06 in launch () #16 0x0804e07b in handle_launcher_request () #17 0x0804e471 in handle_requests () #18 0x0804f08b in main ()
Could you also give some more information about the server? The software it runs, its version, its address? Also does this happen with a particular pop server, or can you reproduce it on other servers too? Also, by saying: >they also continued after I detached and quit gdb do you mean that KMail resumed working properly?
>Also, by saying: >>they also continued after I detached and quit gdb >do you mean that KMail resumed working properly? Yes, because the mailchecks froze when I attached gdb to them. It wasn't an actual hang like the ones that this bug is about. I'm not sure if I understood completely what I'm supposed to do with gdb: am I to attach to pid before or after a hang happens? To clarify: in comment #9 no hang had happened. I just attached gdb to the pids, which made the next mailchecks freeze until I detached. In comment #10 an actual hang did place, after which I attached gdb and did a backtrace. About the mailserver: I don't have precise info about it. A friend recommended using 'telnet <address> 25' to find out more, but I got only this: Trying 193.229.0.46... Connected to mail.kolumbus.fi. Escape character is '^]'. 220 fep32-app.kolumbus.fi ESMTP server ready Fri, 14 Apr 2006 03:44:35 +0300 I'm using SSL encryption (port 995) with clear text authentication.
>am I to attach to pid before or after a hang happens? You are supposed to attach after the hang. > One thing about this bug hunt bothers me, though: when I attached gdb to the kio_pop3 processes, the very next mailchecks hung, and they also continued after I detached and quit gdb. I tried it twice, same thing both times. That's normal. I wouldn't even be surprised if you could get out of a hang by just attaching, interrupting and detaching. > There was a status text "Folder trash compacted succesfully" visible which wouldn't go away, and the status bar read 100% I hadn't noticed this comment before. So, could you test with a single account? i.e. since you have two users on the same mailserver, try interval checking with one of them first, remove/disable checking with the other. See if the hang happens. Then do it for the other account.
As (kind of) already stated in comment #5, the hang has happened with only one mailcheck. But I made doubly sure and tested both my accounts one at a time. Both hung at some point.
Update: Problem still occurs with KDE 3.5.4.
I can confirm this bug. I have been getting exactly the same problem on and off for a couple of years using kmail. I believe it is agravated by network congestion, particularly on the uplink to my ISP (hightly asymmetric link, so this is the most common congestion for me). It appears that there is no timeout in the kio_pop3 process, or that in a specific set of circumstances the timeout is not handled properly. I find that a kill (TERM, not -9) to the kio_pop3 process causes it to exit, after which subsequent mailbox checks work correctly, or at least have the same chance of working as any other check does. I tend to run my machine 24/7, and have previously come back from weekends away to find the kio_pop3 process is several days old and still stuck.
This could be the same as bug 122457.
Marking as duplicate of the oldest bug about killing kio_pop3. *** This bug has been marked as a duplicate of bug 122457 ***