Version: (using KDE 4.3.4) OS: Linux Installed from: Ubuntu Packages After resuming from suspend to RAM, there is no longer access to IMAP. E.g. attempting to check mail just causes the progress indicator to sit at 0% forever. And when clicking on a folder it attempts to retrieve mail forever. I suspect this is a bug with kio_imap4. The only thing that works is restarting KMail. (I tried e.g. going offline and back online and that doesn't work.)
I have had the same problem for a long time now, and haven't found any other workaround then to close kmail after resuming.
Application: kmail (1.13.0) KDE Platform Version: 4.4.00 (KDE 4.4.0) Qt Version: 4.6.1 Operating System: Linux 2.6.31-19-generic x86_64 Distribution: Ubuntu 9.10 -- Information about the crash: If I suspend my computer while KMail is accessing one of my IMAP account, then after the resume KMail fails to access the IMAPs accounts : it just displays the blue loading screen undefinitely. On the bottom right, the list of ongoin operations shows a stalled operation "Checking XXX". Today, I tried to cancell that operation, and KMail crashed. A few more informations : - in previous occurences of this bug, I had closed KMail and it left me with a kio_imap process using 100% of the CPU - I was at one place (and with a given IP) when I suspended my computer, and at another place (with another IP) when I resumed it - I haven't tried with POP -- Backtrace: Application: KMail (kmail), signal: Segmentation fault [Current thread is 1 (Thread 0x7fd8b4fed7f0 (LWP 2868))] Thread 2 (Thread 0x7fd8978c6910 (LWP 8017)): #0 pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:220 #1 0x00007fd8b233d662 in QWaitConditionPrivate::wait (this=<value optimized out>, mutex=0x1adff10, time=30000) at thread/qwaitcondition_unix.cpp:85 #2 QWaitCondition::wait (this=<value optimized out>, mutex=0x1adff10, time=30000) at thread/qwaitcondition_unix.cpp:159 #3 0x00007fd8b2332a39 in QThreadPoolThread::run (this=0x1ada270) at concurrent/qthreadpool.cpp:140 #4 0x00007fd8b233c745 in QThreadPrivate::start (arg=0x1ada270) at thread/qthread_unix.cpp:248 #5 0x00007fd8afc36a04 in start_thread (arg=<value optimized out>) at pthread_create.c:300 #6 0x00007fd8b1b0c80d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #7 0x0000000000000000 in ?? () Thread 1 (Thread 0x7fd8b4fed7f0 (LWP 2868)): [KCrash Handler] #5 0x00007fd8b2443fa3 in QObjectPrivate::isSignalConnected (sender=0x1e98630, m=<value optimized out>, local_signal_index=4, argv=0x7fffcdd35060) at kernel/qobject_p.h:227 #6 QMetaObject::activate (sender=0x1e98630, m=<value optimized out>, local_signal_index=4, argv=0x7fffcdd35060) at kernel/qobject.cpp:3200 #7 0x00007fd8ab6ab587 in KPIM::ProgressItem::progressItemStatus(KPIM::ProgressItem*, QString const&) () from /usr/lib/libkdepim.so.4 #8 0x00007fd8b3a3e081 in ?? () from /usr/lib/libkmailprivate.so.4 #9 0x00007fd8b3a4412c in ?? () from /usr/lib/libkmailprivate.so.4 #10 0x00007fd8b2443d3f in QMetaObject::activate (sender=0x17a7ea0, m=<value optimized out>, local_signal_index=<value optimized out>, argv=0x0) at kernel/qobject.cpp:3275 #11 0x00007fd8b3a083e3 in ?? () from /usr/lib/libkmailprivate.so.4 #12 0x00007fd8b3a12a0c in ?? () from /usr/lib/libkmailprivate.so.4 #13 0x00007fd8b3a18deb in ?? () from /usr/lib/libkmailprivate.so.4 #14 0x00007fd8b3a1e445 in ?? () from /usr/lib/libkmailprivate.so.4 #15 0x00007fd8b2443d3f in QMetaObject::activate (sender=0x17025c0, m=<value optimized out>, local_signal_index=<value optimized out>, argv=0x0) at kernel/qobject.cpp:3275 #16 0x00007fd8aebdc9df in KIO::Scheduler::slaveConnected (this=0x6, _t1=0x1f8aad0) at ./scheduler.moc:125 #17 0x00007fd8aebddd9c in KIO::SchedulerPrivate::slotSlaveConnected (this=0x16cc600) at ../../kio/kio/scheduler.cpp:1038 #18 0x00007fd8aebe3784 in KIO::Scheduler::qt_metacall (this=0x17025c0, _c=QMetaObject::InvokeMetaMethod, _id=<value optimized out>, _a=0x7fffcdd35800) at ./scheduler.moc:110 #19 0x00007fd8b2443d3f in QMetaObject::activate (sender=0x1f8aad0, m=<value optimized out>, local_signal_index=<value optimized out>, argv=0x0) at kernel/qobject.cpp:3275 #20 0x00007fd8aebf5c2d in KIO::SlaveInterface::dispatch (this=0x1f8aad0, _cmd=103, rawdata=...) at ../../kio/kio/slaveinterface.cpp:220 #21 0x00007fd8aebf2f83 in KIO::SlaveInterface::dispatch (this=0x1f8aad0) at ../../kio/kio/slaveinterface.cpp:91 #22 0x00007fd8aebe72e6 in KIO::Slave::gotInput (this=0x1f8aad0) at ../../kio/kio/slave.cpp:324 #23 0x00007fd8aebe74cc in KIO::Slave::qt_metacall (this=0x1f8aad0, _c=QMetaObject::InvokeMetaMethod, _id=<value optimized out>, _a=0x7fffcdd35c20) at ./slave.moc:82 #24 0x00007fd8b2443d3f in QMetaObject::activate (sender=0x1f8e2b0, m=<value optimized out>, local_signal_index=<value optimized out>, argv=0x0) at kernel/qobject.cpp:3275 #25 0x00007fd8aeb05aa7 in KIO::ConnectionPrivate::dequeue (this=0x1f82070) at ../../kio/kio/connection.cpp:82 #26 0x00007fd8aeb05bcd in KIO::Connection::qt_metacall (this=0x1f8e2b0, _c=QMetaObject::InvokeMetaMethod, _id=<value optimized out>, _a=0x1e8fcd0) at ./connection.moc:79 #27 0x00007fd8b2440c79 in QObject::event (this=0x1f8e2b0, e=0x17f1830) at kernel/qobject.cpp:1248 #28 0x00007fd8b2903fac in QApplicationPrivate::notify_helper (this=0x1430ab0, receiver=0x1f8e2b0, e=0x17f1830) at kernel/qapplication.cpp:4298 #29 0x00007fd8b290a59b in QApplication::notify (this=0x7fffcdd36840, receiver=0x1f8e2b0, e=0x17f1830) at kernel/qapplication.cpp:4181 #30 0x00007fd8b4a0bd16 in KApplication::notify (this=0x7fffcdd36840, receiver=0x1f8e2b0, event=0x17f1830) at ../../kdeui/kernel/kapplication.cpp:302 #31 0x00007fd8b2430f3c in QCoreApplication::notifyInternal (this=0x7fffcdd36840, receiver=0x1f8e2b0, event=0x17f1830) at kernel/qcoreapplication.cpp:704 #32 0x00007fd8b24336b7 in QCoreApplication::sendEvent (receiver=0x0, event_type=<value optimized out>, data=0x13888b0) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:215 #33 QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=<value optimized out>, data=0x13888b0) at kernel/qcoreapplication.cpp:1345 #34 0x00007fd8b245a923 in QCoreApplication::sendPostedEvents (s=<value optimized out>) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:220 #35 postEventSourceDispatch (s=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:276 #36 0x00007fd8a92c1bce in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #37 0x00007fd8a92c5598 in ?? () from /lib/libglib-2.0.so.0 #38 0x00007fd8a92c56c0 in g_main_context_iteration () from /lib/libglib-2.0.so.0 #39 0x00007fd8b245a463 in QEventDispatcherGlib::processEvents (this=0x1388000, flags=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:412 #40 0x00007fd8b29b37ee in QGuiEventDispatcherGlib::processEvents (this=0x6, flags=<value optimized out>) at kernel/qguieventdispatcher_glib.cpp:204 #41 0x00007fd8b242f862 in QEventLoop::processEvents (this=<value optimized out>, flags=) at kernel/qeventloop.cpp:149 #42 0x00007fd8b242fc3c in QEventLoop::exec (this=0x7fffcdd36670, flags=) at kernel/qeventloop.cpp:201 #43 0x00007fd8b243397b in QCoreApplication::exec () at kernel/qcoreapplication.cpp:981 #44 0x0000000000403572 in _start () The current source language is "auto; currently asm". The current source language is "auto; currently c".
PS: I think that #226748 is a duplicate of this bug.
*** Bug 226748 has been marked as a duplicate of this bug. ***
For some folders doing F5 does fork a imap process for others not. Also restarting kmail does not always fix this. After restart of kmail the folders for which no imap is forked are the same. Folders for which an imap is forked reading of messages does not happen. When quitting kmail the imap processe do not terminate. When killing this they terminate after about 7 seconds. My current workaround: 1) Move ~/.kde4/share/apps/kmail/imap out of the way 2) Start kmail, let it complain about missing folders 3) Quit kmail, restore ~/.kde4/share/apps/kmail/imap and restart (kmail) I have this problem independently on three computers running 4.4.0 from opsenSUSE repos. Please set severity to major.
What works for me is to close kmal and kill all imap processes (killall -9 kio_imap).After that everything works fine. I have this problem since kde 4.0 ... so it seems to be an architecture problem of the kio imap processes.
> What works for me is to close kmal and kill all imap processes (killall -9 kio_imap) Yes, doing so _before_ suspending prevents from problems after resume. But if you forget this you will have unaccessible mail folders sooner or later. So this is not only a problem with KIO (if I kill all kmail and kio_imap4 processes and restart then email folders remain unaccessible). Hmm, also with 4.4.1 my ~/.kde4/share/apps/kmail/imap is gone. I guess mail caching is now done wiht akonadi DB.
> Hmm, also with 4.4.1 my ~/.kde4/share/apps/kmail/imap is gone. No, its still there (I accidentally looked in ~/.kde/...)
*** This bug has been marked as a duplicate of bug 213662 ***