[Bug 172410] imap connection not automatically restored

Raúl rasasi78 at gmail.com
Wed Oct 21 10:57:28 BST 2009


https://bugs.kde.org/show_bug.cgi?id=172410


Raúl <rasasi78 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rasasi78 at gmail.com




--- 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.


More information about the Kdepim-bugs mailing list