https://bugs.kde.org/show_bug.cgi?id=172410
Raúl <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #5 from Raúl <rasasi78 gmail com> 2009-10-21 11:57:21 --- Hello: I'm also seeing this problem, which likely dupes https://bugs.kde.org/show_bug.cgi?id=186936 and https://bugs.kde.org/show_bug.cgi?id=132088. I also have this problem when I hibernate/resume. Debian testing with KDE 4.3.1. I think it's kio_impa4 to blame. Looks like connection is so badly interrupted that it can't be recovered. IMHO, in this case some sort of recovery procedure should be used so retries are timeout, and the connection is given up. Once that is done, a new connection should be carried out. Backtrace of the kio_imap4 when problem is reproduced looks like this: #0 0x00007f7d8a69beb3 in __select_nocancel () from /lib/libc.so.6 #1 0x00007f7d891bbf52 in QNativeSocketEnginePrivate::nativeSelect (this=0x1cce720, timeout=-1, checkRead=<value optimized out>, checkWrite=<value optimized out>, selectForRead=0x7fff27148baf, selectForWrite=0x7fff27148bae) at socket/qnativesocketengine_unix.cpp:888 #2 0x00007f7d891a527c in QNativeSocketEngine::waitForReadOrWrite (this=0x1cce4f0, readyToRead=0x7fff27148baf, readyToWrite=0x7fff27148bae, checkRead=208, checkWrite=255, msecs=-1, timedOut=0x0) at socket/qnativesocketengine.cpp:904 #3 0x00007f7d891b581b in QAbstractSocket::waitForReadyRead (this=0x1cca240, msecs=-1) at socket/qabstractsocket.cpp:1700 #4 0x00007f7d8bf2516f in KIO::SocketConnectionBackend::waitForIncomingTask (this=0x1cc9fd0, ms=-1) at ../../kio/kio/connection.cpp:268 #5 0x00007f7d8c010e60 in KIO::SlaveBase::dispatchLoop (this=0x1cc4f50) at ../../kio/kio/slavebase.cpp:272 #6 0x00007f7d81fabb23 in kdemain (argc=<value optimized out>, argv=0x1c81720) at ../../../kioslave/imap4/imap4.cpp:132 #7 0x0000000000407264 in launch (argc=4, _name=0x1c79b58 "kio_imap4", args=<value optimized out>, cwd=0x0, envc=0, envs=0x1c79bdb "", reset_env=false, tty=0x0, avoid_loops=false, startup_id_str=0x40a0ff "0") at ../../kinit/kinit.cpp:677 #8 0x0000000000407a28 in handle_launcher_request (sock=7, who=<value optimized out>) at ../../kinit/kinit.cpp:1169 #9 0x0000000000407fae in handle_requests (waitForPid=0) at ../../kinit/kinit.cpp:1362 #10 0x000000000040863b in main (argc=2, argv=0x7fff271499d8, envp=0x7fff271499f0) at ../../kinit/kinit.cpp:1793 Also doing further investigation I also realised that kontact was waiting for a pipe input which is connected to itself. I'm sorry but I don't have a backtrace for that right now. One hypothesis is that pipe should be somehow related to kio_imap4 and it's created once kontact(or kmail) launches the imap kioslave. Once the imap kioslave is stalled or its connnection to kioslave is lost, kontact doesn't destoy that pipe and relaunches a new imap kioslave. Maybe I'm right, or maybe rationale is plain wrong. I hope someone could tell. Regards, -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ Kdepim-bugs mailing list [email protected] https://mail.kde.org/mailman/listinfo/kdepim-bugs
