Version: 4.2 RC1 (using Devel) Compiler: gcc (GCC) 4.1.2 20070214 ( (gdc 0.24, using dmd 1.020)) (Gentoo 4.1.2 p1.1) OS: Linux Usually it works fine, but often when I switch to it, it takes seconds (maybe a minute) to start drawing itself, and likes to eat ~90% CPU. Even after I issued the X to close it, KWin asked me to terminate it, and once the window disappeared, Kontact continued to eat CPU in the background until I kill-9'd it.
Provide which component you have active in kontact. What happens if you disable all, but one component in kontact? Can you determine which of the component is the reason for kontact being a cpu hog.
"Mail" is currently active, and I disabled everything else that I could, so only Mail, To-do List, Journal, and Time Tracker are left. It seems to occur when a redraw is needed, not during actual use. Though redraws are not ALWAYS delayed.
#0 0x000000398ca0d20b in write () from /lib/libpthread.so.0 #1 0x00007f4701354b47 in KMComposeWin::slotContinueAutoSave (this=0x2ab0de0) at /var/tmp/portage/kde-base/kmail-4.1.96/work/kmail-4.1.96/kmail/kmcomposewin.cpp:668 #2 0x00007f47013621dd in KMComposeWin::qt_metacall (this=0x2ab0de0, _c=QMetaObject::InvokeMetaMethod, _id=86, _a=0x7fff1788a5a0) at /var/tmp/portage/kde-base/kmail-4.1.96/work/kmail_build/kmail/kmcomposewin.moc:316 #3 0x00000039929521ec in QMetaObject::activate () from /usr/lib64/qt4/libQtCore.so.4 #4 0x00007f470135efbf in KMComposeWin::applyChangesDone (this=0x2ab0de0, _t1=true) at /var/tmp/portage/kde-base/kmail-4.1.96/work/kmail_build/kmail/kmcomposewin.moc:331 #5 0x00007f470135f012 in KMComposeWin::slotComposerDone (this=0x2ab0de0, rc=true) at /var/tmp/portage/kde-base/kmail-4.1.96/work/kmail-4.1.96/kmail/kmcomposewin.cpp:1983 #6 0x00007f4701362194 in KMComposeWin::qt_metacall (this=0x2ab0de0, _c=QMetaObject::InvokeMetaMethod, _id=83, _a=0x7fff1788a720) at /var/tmp/portage/kde-base/kmail-4.1.96/work/kmail_build/kmail/kmcomposewin.moc:313 #7 0x00000039929521ec in QMetaObject::activate () from /usr/lib64/qt4/libQtCore.so.4 #8 0x00007f470159ae65 in MessageComposer::done (this=0x20804c40, _t1=true) at /var/tmp/portage/kde-base/kmail-4.1.96/work/kmail_build/kmail/messagecomposer.moc:80 #9 0x00007f47015a8e9b in MessageComposer::emitDone (this=0x20804c40, ok=true) at /var/tmp/portage/kde-base/kmail-4.1.96/work/kmail-4.1.96/kmail/messagecomposer.cpp:412 #10 0x00007f47015a8f0e in MessageComposer::doNextJob (this=0x20804c40) at /var/tmp/portage/kde-base/kmail-4.1.96/work/kmail-4.1.96/kmail/messagecomposer.cpp:388 #11 0x00007f47015a9032 in MessageComposer::slotDoNextJob (this=0x20804c40) at /var/tmp/portage/kde-base/kmail-4.1.96/work/kmail-4.1.96/kmail/messagecomposer.cpp:435 #12 0x00007f47015a90ad in MessageComposer::qt_metacall (this=0x20804c40, _c=QMetaObject::InvokeMetaMethod, _id=1, _a=0x7fff1788a880) at /var/tmp/portage/kde-base/kmail-4.1.96/work/kmail_build/kmail/messagecomposer.moc:69 #13 0x00000039929521ec in QMetaObject::activate () from /usr/lib64/qt4/libQtCore.so.4 #14 0x00000039929589ff in ?? () from /usr/lib64/qt4/libQtCore.so.4 #15 0x000000399294cecb in QObject::event () from /usr/lib64/qt4/libQtCore.so.4 #16 0x00007f470b42955e in QApplicationPrivate::notify_helper () from /usr/lib64/qt4/libQtGui.so.4 #17 0x00007f470b42e0af in QApplication::notify () from /usr/lib64/qt4/libQtGui.so.4 #18 0x00007f470bfc75f4 in KApplication::notify (this=0x7fff1788b390, receiver=0x2113ab10, event=0x7fff1788af90) at /var/tmp/portage/kde-base/kdelibs-4.1.96/work/kdelibs-4.1.96/kdeui/kernel/kapplication.cpp:307 #19 0x000000399293e0c8 in QCoreApplication::notifyInternal () from /usr/lib64/qt4/libQtCore.so.4 #20 0x0000003992967fe7 in ?? () from /usr/lib64/qt4/libQtCore.so.4 #21 0x0000003992968bf8 in QEventDispatcherUNIX::processEvents () from /usr/lib64/qt4/libQtCore.so.4 #22 0x00007f470b4b05d3 in ?? () from /usr/lib64/qt4/libQtGui.so.4 #23 0x000000399293d425 in QEventLoop::processEvents () from /usr/lib64/qt4/libQtCore.so.4 #24 0x000000399293d58a in QEventLoop::exec () from /usr/lib64/qt4/libQtCore.so.4 #25 0x000000399293f3fe in QCoreApplication::exec () from /usr/lib64/qt4/libQtCore.so.4 #26 0x00000000004040f2 in main (argc=1, argv=0x7fff1788b8a8) at /var/tmp/portage/kde-base/kontact-4.1.96/work/kontact-4.1.96/kontact/src/main.cpp:218
The QMetaObject::activate functions seem to take a long time to 'finish'...
Also, it does continue eating CPU even once it reaches QEventLoop::exec
I am faced with similar problems, but I am unsure if it is the same bug: Kontact's mail component becomes stalled or at least unusably slow at times. CPU usage still seems to be 10% to 30% during those phases, and memory consumption is not spectacular either. Yet, normal typing or email browsing becomes impossible. Waiting helps in most cases, but the problem became very frequent recently, and it sometimes occurs even during normal email browsing/viewing (though I do have open email editing windows in the background most of the time). Overall, Kmail/Kontact becomes hard to use with this behaviour and I consider migrating my mail. I am unsure if this is the same problem reported here. I am running KMail 1.10.3 on KDE 4.1.3 Kubuntu. I have many stored emails (some gigabytes) but the folders I usually view are small. I have never needed to kill -9 Kontact, since the problem usually ceased after some minutes (during which I cannot use my mail client). Bug 115331 talks of similar problems, but related to indexing (not sure how the Kubuntu packages were compiled). Bug 91108 also mentions these issues, though also in connection with another problem which is the main subject of Bug 183752. Other CPU-usage bugs include: 161633, 158949, 141993, 126894, 89345, 107649 (maybe this is my problem?), 137033, 140667 (crash involved), 143453 (crash involved). Many of those bugs are blockers for using Kontact/Kmail. Yet the overwhelming majority is "unconfirmed", some are "new", none is "assigned". All of this should be collected and consolidated somewhere. There seem to be many causes involved, but I guess there are duplicates.
Highly relevant, I think: luke-jr@tsuruki ~ $ ps -eo size,args | sort -n | tail -n 1 2207856 /usr/bin/kontact If I am reading this correctly, Kontact is demanding 2.2 GB of memory, more than my machine has.
Mem: 2059992k total, 2042064k used, 17928k free, 11324k buffers Swap: 8048508k total, 5091464k used, 2957044k free, 94244k cached kquitapp kontact Mem: 2059992k total, 1866616k used, 193376k free, 9328k buffers Swap: 8048508k total, 3028392k used, 5020116k free, 107140k cached
Created attachment 31171 [details] valgrind --leak-check=full kontact 2>&1 | bzip2 -9 > kontact.valgrind.log.bz2
I have found that my problem is not CPU usage, even though the UI behaves as if this is the problem. Instead, the bottleneck in my case seems to be hard disk usage due to frequent index file updates. See Bug 166653 for details.
Just to get more information: Do you have searches? (at the bottom of the folder tree) Does it happens after using kmail during sometime or inmediatelly?
No searches. At first start, Kontact is using 70 MB RAM.
I've suffered your initial problem sometimes now, expecially when I start kmail from my builds after running it from the distro. It gets working in createIndexFromContents a lot of time. And after I kill it and start again, it works normally. By the way, using kmail in a PII 200Mhz with an IMAP account to gmail took >10 minutes to get all the 6000 mail headers (with 95% cpu usage). It uses 155Mb of Virtual Memory. Opera, with a similar configuration, only took 5 minutes,50% CPU and 121Mb of Virtual Memory.
[WORKAROUND] Since I only use KDE at my job, I really need Kontact to work. So I downloaded the source RPM and patched it so it stops the indexing process. Now I can work again! No more 15 minutes delays every 16 minutes! I know the workaround is not a FIX (and it an ungly solution) but since I don't really need the full text search, I just disabled it and use a filesystem "flag" to turn it on whenever I need it. --- BUILD/kdepim-4.2.0/kmail/kmfoldersearch.cpp 2008-11-19 08:19:06.000000000 -0200 +++ kmfoldersearch.cpp 2009-02-20 19:54:04.000000000 -0300 @@ -252,7 +252,11 @@ void KMSearch::slotProcessNextBatch() { - if ( !running() ) { + char *flag = "/tmp/kontact.reindex"; + struct stat buffer; + int reindex = (stat(flag, &buffer) == 0); + + if ( !running() || !reindex ) { return; } @@ -273,6 +277,9 @@ } else { --mRemainingFolders; } + if (mRemainingFolders==0) { + unlink(flag); + } mProcessNextBatchTimer->start( 0 ); return; }
Thank you for taking the time to file a bug report. KMail2 was released in 2011, and the entire code base went through significant changes. We are currently in the process of porting to Qt5 and KF5. It is unlikely that these bugs are still valid in KMail2. We welcome you to try out KMail 2 with the KDE 4.14 release and give your feedback.