Bug 172410

I hate this. After suspend/resume kmail shows an error (I may post it later when it happens again) and won't connect to imap servers. Usually closing kmail, then waiting a few seconds before starting it again helps. But I it happenned once or twice to me that I had to kill some imap processes to make it work again. This is in KDE 4.2.0.

The process for the imaps://posta.tuke.sk protocol died unexpectedly.

Unexpected Program Termination 
Unexpected Program Termination
The program on your computer which provides access to the imaps://posta.tuke.sk protocol has unexpectedly terminated.
Details of the request:
URL: (unknown)
Date and time: Monday 09 February 2009 23:18
Additional information: imaps://posta.tuke.sk
Possible causes:
This is most likely to be caused by a bug in the program. Please consider submitting a full bug report as detailed below.
Possible solutions:
Update your software to the latest version. Your distribution should provide tools to update your software.
When all else fails, please consider helping the KDE team or the third party maintainer of this software by submitting a high quality bug report. If the software is provided by a third party, please contact them directly. Otherwise, first look to see if the same bug has been submitted by someone else by searching at the KDE bug reporting website. If not, take note of the details given above, and include them in your bug report, along with as many other details as you think might help.

Still exists in KDE 4.2.1

I am having the same issue. After a suspend/resume I have to restart kmail before being able to fully get new messages through imap. I say fully because it might download 1 or 2 folders (out of 8) but the inbox is never updated. Sometimes I will need to abort the stalled connection before checking for new mail but in order to get new messages in my inbox I need to restart kmail.

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,

I'm surprised that this still doesn't work. But since I switched to Thunderbird few months ago.... :) I recommend the others who have the same problem to do the same.

Merging with 186936

*** This bug has been marked as a duplicate of bug 186936 ***