Version: 1.12.4 (using 4.3.4 (KDE 4.3.4), Debian packages) Compiler: cc OS: Linux (x86_64) release 2.6.30-2-amd64 What more information could I give? No idea? Kmail very often blocks up to 50% of CPU without ny reason. None of my accounts loading or sending mails. The performance is very low. Mails cannot be written, other applications are slow as well. Normal situation: Kmail uses 0-1% CPU Blocking situation: Kmail uses up to 50% CPU
After stopping and restarting kmail kmail is much faster. Even when donwloading messages from my several accounts after the restart of kmail everything works fine. The effect of kmail beeing very slow seams to appear especially after the first start but I am not sure about that.
No, it has nothing to do with the first start. The effect can occur at any time. It sometimes ends after a time by itself but very often the problem is so awful that I do have to restart kmail. Even then the problem might reappear.
This is not funny - the application blocks my computer! There is not much of a difference to a crash. Severety is high! (Can I change that?) Sorry but I do need help on that because this is no testing computer but it is productively used! Martin
Is this maybe a duplicate of bug 219687?
Hello Thomas, I cannot confirm this yet because it looks as if the other bug has to do with sending or different actions. In my case nothing happenes but Kmail uses a lot of CPU. Is there anything I can do, so that you can analyse what happens on my machine? Can I start kmail in debug mode or something like that? (Additional info: I deactivated Strigi file indexer. Can't say if that helps or not.) Thank you for your help! Martin
Deactivating Strigi file indexer did not change anything! Still CPU usage 40-50%. When the effect appears it will take up to ~15-30 Min untill the CPU usage reaches a normal range. Additional question: How much disk space in /tmp does KMail need approximately? Regards, Martin
Hmm, your CPU usage problem is strange, especially since you say that the KMail process uses 50% for 30 minutes. I don't know where that could come from. The only thing you could do is attaching GDB to kmail, interrupting the application and see if the backtrace is suspicious. > Additional question: How much disk space in /tmp does KMail need approximately? No idea. I think for mail fetching with POP it needs at least twice the size of the incoming message. When viewing a mail, it also needs twice the size. Could be that other parts of KMail also use /tmp, but I really have no idea.
Hi Thomas, thank's for the reply! (In reply to comment #7) > Hmm, your CPU usage problem is strange, especially since you say that the KMail > process uses 50% for 30 minutes. I don't know where that could come from. The > only thing you could do is attaching GDB to kmail, interrupting the application > and see if the backtrace is suspicious. What is GDB - debug? - and how do I activate this? Regards, Martin
> What is GDB - debug? - and how do I activate this? If you don't know what GDB is, then you should probably not pursue this any further. GDB is a debugger, but it needs some knowledge to use the tool, especially when trying to debug high CPU, and I couldn't find a nice tutorial with Google.
Hi Thomas, I can try to find out how to use GDB. It is installed at my machine and it this should be a good way to finbd out the reason that makes my machine slow. Regards, Martin
> I can try to find out how to use GDB. It is installed at my machine and it > this should be a good way to finbd out the reason that makes my machine slow. Ok, this is how you use GDB for this: 1. Attach GDB to the KMail process: gdb --pid `pidof kmail` 2. When GDB is done attaching, it has interrupted the application. Type "continue" to let it continue. 3. Press Ctrl+C at any time time to interrupt the application, and type "continue" again to let it continue 4. When KMail is interrupted, type "backtrace" to get a backtrace. That will show you in which code path KMail currently is. If you manage to interrupt KMail when it is using CPU, the backtrace should show which function uses the CPU and how it is called. Try interrupting KMail several times, when it is using CPU. If the backtraces have similar function names, then those functions are likely the ones using the CPU. If you manage to find a backtrace that's nearly always the same when KMail is using CPU, post it here.
Hi Thomas, the situation improved a little bit. Some weeks everything seemed to be ok but then the problem reoccured. Now we have CPU usage up to 20%. This occurs in cycles! This is the result of GDB. I hope, what I did is correct and helps: Program received signal SIGINT, Interrupt. 0x00007fe43e12c743 in *__GI___poll (fds=<value optimized out>, nfds=<value optimized out>, timeout=3024) at ../sysdeps/unix/sysv/linux/poll.c:87 87 in ../sysdeps/unix/sysv/linux/poll.c (gdb) backtrace #0 0x00007fe43e12c743 in *__GI___poll (fds=<value optimized out>, nfds=<value optimized out>, timeout=3024) at ../sysdeps/unix/sysv/linux/poll.c:87 #1 0x00007fe4365ac299 in ?? () from /lib/libglib-2.0.so.0 #2 0x00007fe4365ac6ec in g_main_context_iteration () from /lib/libglib-2.0.so.0 #3 0x00007fe43f66d39c in QEventDispatcherGlib::processEvents (this=0xbb9b40, flags=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:407 #4 0x00007fe43eb54f1f in QGuiEventDispatcherGlib::processEvents (this=0x2a74600, flags=<value optimized out>) at kernel/qguieventdispatcher_glib.cpp:202 #5 0x00007fe43f643562 in QEventLoop::processEvents (this=<value optimized out>, flags=...) at kernel/qeventloop.cpp:149 #6 0x00007fe43f643934 in QEventLoop::exec (this=0x7fff597d8f20, flags=...) at kernel/qeventloop.cpp:201 #7 0x00007fe43f645ba4 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:888 #8 0x0000000000402fa9 in main (argc=<value optimized out>, argv=<value optimized out>) at ../../kmail/main.cpp:146 (gdb) next interrupt: Continuing. [New Thread 0x7fe4261b2910 (LWP 13205)] [Thread 0x7fe4261b2910 (LWP 13205) exited] [New Thread 0x7fe4261b2910 (LWP 13225)] [Thread 0x7fe4261b2910 (LWP 13225) exited] ^C Program received signal SIGINT, Interrupt. 0x00007fe43e12c743 in *__GI___poll (fds=<value optimized out>, nf ds=<value optimized out>, timeout=4989) at ../sysdeps/unix/sysv/linux/poll.c:87 87 in ../sysdeps/unix/sysv/linux/poll.c (gdb) backtrace #0 0x00007fe43e12c743 in *__GI___poll (fds=<value optimized out>, nfds=<value optimized out>, timeout=4989) at ../sysdeps/unix/sysv/linux/poll.c:87 #1 0x00007fe4365ac299 in ?? () from /lib/libglib-2.0.so.0 #2 0x00007fe4365ac6ec in g_main_context_iteration () from /lib/libglib-2.0.so.0 #3 0x00007fe43f66d39c in QEventDispatcherGlib::processEvents (this=0xbb9b40, flags=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:407 #4 0x00007fe43eb54f1f in QGuiEventDispatcherGlib::processEvents (this=0x2a74600, flags=<value optimized out>) at kernel/qguieventdispatcher_glib.cpp:202 #5 0x00007fe43f643562 in QEventLoop::processEvents (this=<value optimized out>, flags=...) at kernel/qeventloop.cpp:149 #6 0x00007fe43f643934 in QEventLoop::exec (this=0x7fff597d8f20, flags=...) at kernel/qeventloop.cpp:201 #7 0x00007fe43f645ba4 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:888 #8 0x0000000000402fa9 in main (argc=<value optimized out>, argv=<value optimized out>) at ../../kmail/main.cpp:146 (gdb) next interrupt: Program received signal SIGINT, Interrupt. 0x00007fe43e12c743 in *__GI___poll (fds=<value optimized out>, nf ds=<value optimized out>, timeout=8540) at ../sysdeps/unix/sysv/linux/poll.c:87 87 in ../sysdeps/unix/sysv/linux/poll.c (gdb) backtrace #0 0x00007fe43e12c743 in *__GI___poll (fds=<value optimized out>, nfds=<value optimized out>, timeout=8540) at ../sysdeps/unix/sysv/linux/poll.c:87 #1 0x00007fe4365ac299 in ?? () from /lib/libglib-2.0.so.0 #2 0x00007fe4365ac6ec in g_main_context_iteration () from /lib/libglib-2.0.so.0 #3 0x00007fe43f66d39c in QEventDispatcherGlib::processEvents (this=0xbb9b40, flags=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:407 #4 0x00007fe43eb54f1f in QGuiEventDispatcherGlib::processEvents (this=0x2a74600, flags=<value optimized out>) at kernel/qguieventdispatcher_glib.cpp:202 #5 0x00007fe43f643562 in QEventLoop::processEvents (this=<value optimized out>, flags=...) at kernel/qeventloop.cpp:149 #6 0x00007fe43f643934 in QEventLoop::exec (this=0x7fff597d8f20, flags=...) at kernel/qeventloop.cpp:201 #7 0x00007fe43f645ba4 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:888 #8 0x0000000000402fa9 in main (argc=<value optimized out>, argv=<value optimized out>) at ../../kmail/main.cpp:146 (gdb) next interrupt: Continuing. [New Thread 0x7fe4261b2910 (LWP 13241)] [Thread 0x7fe4261b2910 (LWP 13241) exited] [New Thread 0x7fe4261b2910 (LWP 13270)] [Thread 0x7fe4261b2910 (LWP 13270) exited] [New Thread 0x7fe4261b2910 (LWP 13312)] [Thread 0x7fe4261b2910 (LWP 13312) exited] [New Thread 0x7fe4261b2910 (LWP 13344)] [Thread 0x7fe4261b2910 (LWP 13344) exited] [New Thread 0x7fe4261b2910 (LWP 13361)] [New Thread 0x7fe424b60910 (LWP 13362)] ^C Program received signal SIGINT, Interrupt. 0x00007fe43e12c743 in *__GI___poll (fds=<value optimized out>, nf ds=<value optimized out>, timeout=29999) at ../sysdeps/unix/sysv/linux/poll.c:87 87 in ../sysdeps/unix/sysv/linux/poll.c (gdb) backtrace #0 0x00007fe43e12c743 in *__GI___poll (fds=<value optimized out>, nfds=<value optimized out>, timeout=29999) at ../sysdeps/unix/sysv/linux/poll.c:87 #1 0x00007fe4365ac299 in ?? () from /lib/libglib-2.0.so.0 #2 0x00007fe4365ac6ec in g_main_context_iteration () from /lib/libglib-2.0.so.0 #3 0x00007fe43f66d39c in QEventDispatcherGlib::processEvents (this=0xbb9b40, flags=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:407 #4 0x00007fe43eb54f1f in QGuiEventDispatcherGlib::processEvents (this=0x2a74600, flags=<value optimized out>) at kernel/qguieventdispatcher_glib.cpp:202 #5 0x00007fe43f643562 in QEventLoop::processEvents (this=<value optimized out>, flags=...) at kernel/qeventloop.cpp:149 #6 0x00007fe43f643934 in QEventLoop::exec (this=0x7fff597d6560, flags=...) at kernel/qeventloop.cpp:201 #7 0x00007fe43ef46c7e in QDialog::exec (this=0x7fff597d65f0) at dialogs/qdialog.cpp:498 #8 0x00007fe43fe1d48a in KMComposeWin::slotAttachFile (this=0x3a4df50) at ../../kmail/kmcomposewin.cpp:2283 #9 0x00007fe43fe3f1c1 in KMComposeWin::qt_metacall (this=0x3a4df50, _c=QMetaObject::InvokeMetaMethod, _id=<value optimized out>, _a=0x7fff597d68c0) at ./kmcomposewin.moc:236 #10 0x00007fe43f659df2 in QMetaObject::activate (sender=0x3b38bb0, from_signal_index=<value optimized out>, to_signal_index=6, argv=0xffffffffffffffff) at kernel/qobject.cpp:3112 #11 0x00007fe43eab8147 in QAction::triggered (this=0x2a74600, _t1=false) at .moc/release-shared/moc_qaction.cpp:236 #12 0x00007fe43eab95c0 in QAction::activate (this=0x3b38bb0, event=<value optimized out>) at kernel/qaction.cpp:1167 #13 0x00007fe43ee30eda in QAbstractButtonPrivate::click (this=0x3be9fd0) at widgets/qabstractbutton.cpp:525 #14 0x00007fe43ee31175 in QAbstractButton::mouseReleaseEvent (this=0x3bc9900, e=0x7fff597d7220) at widgets/qabstractbutton.cpp:1115 #15 0x00007fe43eeffc2a in QToolButton::mouseReleaseEvent (this=0x2a74600, e=0xe) at widgets/qtoolbutton.cpp:709 #16 0x00007fe43eb0e37f in QWidget::event (this=0x3bc9900, event=0x7fff597d7220) at kernel/qwidget.cpp:7554 #17 0x00007fe43eabe01d in QApplicationPrivate::notify_helper (this=0xc0c140, receiver=0x3bc9900, e=0x7fff597d7220) at kernel/qapplication.cpp:4065 #18 0x00007fe43eac67ca in QApplication::notify (this=<value optimized out>, receiver=0x3bc9900, e=0x7fff597d7220) at kernel/qapplication.cpp:3767 #19 0x00007fe440ce4de6 in KApplication::notify (this=0x7fff597d90d0, receiver=0x3bc9900, event=0x7fff597d7220) ---Type <return> to continue, or q <return> to quit--- Am Dienstag, 2. März 2010, um 23:11:21 schrieb Thomas McGuire: > https://bugs.kde.org/show_bug.cgi?id=225602 > > > > > > --- Comment #11 from Thomas McGuire <mcguire kde org> 2010-03-02 23:11:07 > --- > > > I can try to find out how to use GDB. It is installed at my machine and > > it this should be a good way to finbd out the reason that makes my > > machine slow. > > Ok, this is how you use GDB for this: > > 1. Attach GDB to the KMail process: > gdb --pid `pidof kmail` > 2. When GDB is done attaching, it has interrupted the application. Type > "continue" to let it continue. > 3. Press Ctrl+C at any time time to interrupt the application, and type > "continue" again to let it continue > 4. When KMail is interrupted, type "backtrace" to get a backtrace. That > will show you in which code path KMail currently is. If you manage to > interrupt KMail when it is using CPU, the backtrace should show which > function uses the CPU and how it is called. > Try interrupting KMail several times, when it is using CPU. If the > backtraces have similar function names, then those functions are likely > the ones using the CPU. If you manage to find a backtrace that's nearly > always the same when KMail is using CPU, post it here. >
> This is the result of GDB. I hope, what I did is correct and helps: What you did was correct. However, you only interrupted KMail when it was actually not busy, which is indicated by the the backtrace, where __GI___poll is always on top, which means KMail is idle and waiting for events.
Hello Thomas, Am Sonntag, 18. April 2010, um 00:29:27 schrieb Thomas McGuire: > However, you only interrupted KMail when it was > actually not busy, which is indicated by the the backtrace, where > __GI___poll is always on top, which means KMail is idle and waiting for > events. > Well, this is exactly the situation that describes the bug: No active processes in KMail but KMail "eats" CPU ressources! So, what can we do now? Regards, Martin
Hi, another question: What can we do to exclude that the reason for the problem is the power managment (ACPI)? Regards, Martin Am Sonntag, 18. April 2010, um 10:45:27 schrieb Martin Lüchem: > Hello Thomas, > > Am Sonntag, 18. April 2010, um 00:29:27 schrieb Thomas McGuire: > > However, you only interrupted KMail when it was > > actually not busy, which is indicated by the the backtrace, where > > __GI___poll is always on top, which means KMail is idle and waiting for > > events. > > Well, this is exactly the situation that describes the bug: No active > processes in KMail but KMail "eats" CPU ressources! > > So, what can we do now? > > Regards, Martin >
> Well, this is exactly the situation that describes the bug: No active > processes in KMail but KMail "eats" CPU ressources! I guess you mean active threads, not processes. KMail can not use CPU without having active threads, I guess your timing for the backtraces was just unlucky. > another question: What can we do to exclude that the reason for the problem > is the power managment (ACPI)? It would surprise me if this bug had anything to do with ACPI, that is lower level than all of the KMail code. Why do you think it could be related?
Hello Thomas, Am Sonntag, 18. April 2010, um 23:25:52 schrieb Thomas McGuire: > > Well, this is exactly the situation that describes the bug: No active > > processes in KMail but KMail "eats" CPU ressources! > > I guess you mean active threads, not processes. KMail can not use CPU > without having active threads, I guess your timing for the backtraces was > just unlucky. This is all I can do and all I can say. A little bit simpler: KMail heats my Notebook while I am doing nothing. And the video I sent you describes what I can see in ksysguard. What else could I do? When I kill KMail, the usage of CPU decreases. > > > another question: What can we do to exclude that the reason for the > > problem is the power managment (ACPI)? > > It would surprise me if this bug had anything to do with ACPI, that is > lower level than all of the KMail code. > Why do you think it could be related? > Well sometimes the Notebook seems to be slower when woken up out of "suspend- to-ram". Who knows if that has anything to do with this KMail-Problem? Tell me what I can do to clarify the situation! Thanks for your help! Martin
Hi Thomas, > Hi, > > On Sunday 18 April 2010 14:14:37 you wrote: >> this vid to show you, how KMail uses CPU without any action. > > Yep, the video matches your description. I can of course not tell anything > more from that video. > Are you sure it is not doing a mail check in the background? I thought about that. But therefore I sent you the statistics that shows all "mail processes". Don't you think, that the imap- and pop3-processes should react in this case? Or are there other processes that I can monitor? Regards, Martin Am Sonntag, 18. April 2010, um 23:57:38 schrieb Martin L ü c h e m: > https://bugs.kde.org/show_bug.cgi?id=225602 > > > > > > --- Comment #17 from Martin L ü c h e m <Heinrich20 gmx de> 2010-04-18 > 23:57:37 --- Hello Thomas, > > Am Sonntag, 18. April 2010, um 23:25:52 schrieb Thomas McGuire: > > > Well, this is exactly the situation that describes the bug: No active > > > processes in KMail but KMail "eats" CPU ressources! > > > > I guess you mean active threads, not processes. KMail can not use CPU > > without having active threads, I guess your timing for the backtraces > > was just unlucky. > > This is all I can do and all I can say. A little bit simpler: KMail heats > my Notebook while I am doing nothing. And the video I sent you describes > what I can see in ksysguard. What else could I do? When I kill KMail, the > usage of CPU decreases. > > > > another question: What can we do to exclude that the reason for the > > > problem is the power managment (ACPI)? > > > > It would surprise me if this bug had anything to do with ACPI, that is > > lower level than all of the KMail code. > > Why do you think it could be related? > > Well sometimes the Notebook seems to be slower when woken up out of > "suspend- to-ram". Who knows if that has anything to do with this > KMail-Problem? > > Tell me what I can do to clarify the situation! > > Thanks for your help! Martin >
Hi! I urgently need a solution for this problem! It is worse than before and KMail is almost unusable for about 2 hours after the startup. Within this time it blocks the whole system! Thank you for your support! Regards, Martin Am Sonntag, 18. April 2010, um 14:31:10 schrieb M. L.: > Hi, > > another question: What can we do to exclude that the reason for the problem > is the power managment (ACPI)? > > Regards, Martin >
Sorry, I don't have an idea where this problem could be either.
Hello Thomas, Am Dienstag, 20. April 2010, um 13:23:31 schrieb Thomas McGuire: > --- Comment #20 from Thomas McGuire <mcguire kde org> 2010-04-20 13:23:18 > --- Sorry, I don't have an idea where this problem could be either. > One more hint: The strigi services does not run and cannot be started. KNepomuk yes, Strigi no! Any influence? Within "Systemsettings2 I am told, that the service does not run but not a single hint what I could do to solve this problem - strange! Regards, Martin
Hey folks, When I switch of Nepomuk/Strigi services the problem seems to disappear! By the way: Can you tell me why status is "unconfirmed" - because I am the only one? Anyway - I like to be the only one! ;-) - one more hint that shows the direction: Regards! Martin
You are not the only one. I am having the exact same problem. From time to time, kmail will start eating 20% of the CPU even though it is idle. I have the Nepomuk service enabled, I will see what happens if I turn it off and post back. By the way, I have noticed the same 20% CPU "bug" in more applications such as Konqueror and kontact. Have you noticed something like that? Regards.
By the way, I am using Kubuntu 10.04 (64-bit) with KDE 4.4.5
Hallo Nikos Papas, tank you for confirming this. Sometimes I think I am the only one. Maybe some peaople do not see that, working with faster machines. Am Donnerstag, 1. Juli 2010, um 20:05:35 schrieb Nikos Papas: > I have noticed the same 20% CPU "bug" in more applications such as > Konqueror and kontact. Have you noticed something like that? No, in my case it happens only with kmail. Martin
Current system: Version: 1.13.3 (4.4.4 (KDE 4.4.4), Debian packages) Compiler: cc OS: Linux (x86_64) release 2.6.32-5-amd64
as this bug idles and the severity and configuration changed I changed the status of this bug! *** This bug has been marked as a duplicate of bug 243569 ***
Hello! Sorry to be the bearer of bad news, but this version of Kmail has been unmaintained for many years so I am closing this bug. Please try using the latest version of Kmail to see if your issue persists. If it does, please submit a new bug in "kmail2". Thank you!