Version: (using KDE KDE 3.5.1) Installed from: FreeBSD Ports Compiler: gcc version 3.4.4 [FreeBSD] 20050518 OS: FreeBSD Sometimes a POP transfer (TSL) will hang. Kmail will continue to transfer email from other accounts, but the hung will gets stuck. The hang only occurs with one account that is at the other end of a VPN over a Sprint Broadband connection (meaning a slow, lossy uplink). I have tried different POP servers, imap-uw-2004g_1 (though only using the POP portion) and dovecot-1.0.b3 (again, only POP, not IMAP). The only way I can clear the wedge is to edit my mailbox on the server and delete the first mail message. Sometimes I must delete the first couple mail messages. Then kmail will successfully POP on its next attempt. The POP transfer usually wedges in the middle of retrieving more than one message. If I manually cancel the transfer and the restart, it hangs immediately. As mentioned above, I must manually delete the first message from my mail file before kmail can POP messages from that server again. It even stays wedged if I quit kmail and then restart it (or rather quit and restart kontact). I have kmail configured to check for new mail every minute. I do not see any error messages on the server. The kmail machine and the server are sync'd to each other (and outside references) using NTP, so their clocks are very close. I believe I first noticed this problem in the 3.4 branch. Probably one of the later 3.4 release. This was not a problem for many earlier kde releases. But both the kmail machine's OS and the server's OS have also been updated over time, so I can't rule out their influence on this problem. Other users using the same POP server (on a local network, no VPN), running Windows and mozilla have not noticed any problems retrieving their mail. My gut tells me something in my VPN link (which is a bit lossy and has slow upspeeds) is causing problems to kmail.
A few more details. I've discovered kmail is leaving a number of kio_pop3 processes behind when this happens. Perhaps it is normal for kio_pop3 processes to keep running, but if they are supposed to exit when the popping is complete, then this might be related to the problem I am seeing. ps -lw shows they are blocked on the kserel channel.
I no longer have the slow sprintbroadband connection, but I'm still seeing the problem with a fast cable connection. Here is a gdb backtrace from a wedged pop process. I hope the proves useful to someone as this is a very annoying problem. (gdb) info thread * 3 LWP 100142 0x294417dd in read () from /lib/libc.so.6 2 Thread 0x805d000 (runnable) 0x294417df in read () from /lib/libc.so.6 1 Thread 0x833fa00 (LWP 100139) 0x2938446b in pthread_testcancel () from /usr/lib/libpthread.so.2 (gdb) thread 2 [Switching to thread 2 (Thread 0x805d000 (runnable))]#0 0x294417df in read () from /lib/libc.so.6 (gdb) bt #0 0x294417df in read () from /lib/libc.so.6 #1 0x2936d19a in read () from /usr/lib/libpthread.so.2 #2 0x297409d1 in BIO_sock_should_retry () from /lib/libcrypto.so.4 #3 0x297a93c3 in BIO_read () from /lib/libcrypto.so.4 #4 0x298c8cf9 in SSL_set_msg_callback () from /usr/lib/libssl.so #5 0x298c9922 in ssl3_read_bytes () from /usr/lib/libssl.so #6 0x298cb035 in ssl3_renegotiate_check () from /usr/lib/libssl.so #7 0x298c652e in SSL_read () from /usr/lib/libssl.so #8 0x2821310c in KOpenSSLProxy::SSL_read (this=0x8363160, ssl=0x83b4400, buf=0xbfbfd1b0, num=4095) at kopenssl.cc:661 #9 0x28203317 in KSSL::read (this=0x8347a40, buf=0xbfbfd1b0, len=4095) at kssl.cc:485 #10 0x282677bb in KIO::TCPSlaveBase::read (this=0x8349000, data=0xbfbfd1b0, len=4095) at tcpslavebase.cpp:174 #11 0x296bd321 in POP3Protocol::myRead () from /usr/local/lib/kde3/kio_pop3.so #12 0x296c2727 in POP3Protocol::get () from /usr/local/lib/kde3/kio_pop3.so #13 0x2826b1a1 in KIO::SlaveBase::dispatch (this=0x8349000, command=67, data=@0xbfbfe320) at slavebase.cpp:1020 #14 0x28269d05 in KIO::SlaveBase::dispatchLoop (this=0x8349000) at slavebase.cpp:290 #15 0x296bcfe0 in kdemain () from /usr/local/lib/kde3/kio_pop3.so #16 0x0804f21d in launch (argc=4, _name=0x8345404 "kio_pop3", args=0x8345486 "", cwd=0x0, envc=0, envs=0x834548a "", reset_env=false, tty=0x0, avoid_loops=96, startup_id_str=0x805189c "0") at kinit.cpp:639 #17 0x0804f8ca in handle_launcher_request (sock=8) at kinit.cpp:1203 #18 0x0804fe6c in handle_requests (waitForPid=0) at kinit.cpp:1406 #19 0x08050465 in main (argc=2, argv=0xbfbfe980, envp=0xbfbfe98c) at kinit.cpp:1850
This could be the same as bug 124185.
*** Bug 131013 has been marked as a duplicate of this bug. ***
*** Bug 124185 has been marked as a duplicate of this bug. ***
*** Bug 139630 has been marked as a duplicate of this bug. ***
Do you still need to kill kio_pop3 with more recent kmail versions?
No, I do not have to kill kio_pop3 anymore. I do often have to exit kontact and restart it when things get wedged, but I don't know if that condition is related to this bug.
Sorry, jumped the gun with that last comment. I'm using imap now, not pop3. So, I can't confirm this problem has gone away.
But we need infos from someone who does use kio_pop :)