|Summary:||kontact/kmail consumes 100% cpu when processing attachments and takes ages to complete|
|Product:||[Applications] kontact||Reporter:||hwj <bmm817-fc2>|
|Component:||general||Assignee:||kdepim bugs <kdepim-bugs>|
|Latest Commit:||Version Fixed In:|
Description hwj 2010-06-07 07:31:14 UTC
Version: unspecified (using KDE 4.3.5) OS: Linux kmail version is 1.12.4 I have configured my incoming mail so that it is retrieved from my provider with fetchmail and passed to postfix. postfix does basic spam filtering and delivers the incoming messages to the local mailboxes in /var/mail -- so far everything is working just fine. My problem: Since upgrading to KDE 4.3.5 on SuSE 11.2 I'm experiencing the following problems with KMail / Kontact (applies to both). Previous versions of KDE (4.3.4 was last I had installed) did not show this problem. When Kmail picks up messages that have an attachment of any kind from the local mailbox, then KMail becomes unresponsive and starts to consume 100% CPU. This also happens when mails are ready to be picked up and Kmail is started. In the latter case the GUI is not drawn until the spook is over... Depending on the size of the attachment, it takes _hours_ (I've experienced more than 20 hours for a 500 KB attachment) until Kmail turns back to a usable state again and the mail finally becomes visible in Kmail's inbox. The problem is reproduceable at will with any mail with an attachment picked up from the local inbox. New mails which are delivered to the local mailbox during this 'heavy duty' task get picked up (i.e. they are removed from the local mailbox), but never appear in KMail. In fact these messages are lost. Reproducible: Always Steps to Reproduce: a) kmail NOT active: Wait until a mail with attachment arrives in local mailbox, then start kmail b) kmail active: Problem occurs as soon a mail with attachment is delivered to local mailbox. Actual Results: kmail is unresponsive with 100% cpu consumtion. Depending on size of mail attachment, this state lasts for several hours, but it does terminate. New mails delivered while kmail is in this 'busy' state are taken from the inbox, but never appear in kmail -> THESE MAILS ARE LOST! I have several times used gdb to attach to the KMail / Kontact process while the process was in this 'busy state' to produce a stack trace. All of these traces look similar to the following: prompt>ps -ef | grep kontact me 8215 1 7 20:47 ? 00:01:22 /usr/bin/kontact prompt>gdb -p 8215 GNU gdb (GDB) SUSE (126.96.36.19990930-2.4) [...stuff deleted...] Attaching to process 8215 Reading symbols from /usr/bin/kontact...Missing separate debuginfo for /usr/bin/kontact Try: zypper install -C "debuginfo(build-id)=980aec264983df3a787a141907cfea009a359d22" (no debugging symbols found)...done. [...this repeats about a 100 times for various libraries...stuff deleted...] (gdb) bt #0 0xb6e17519 in QChar::toLower() const () from /usr/lib/libQtCore.so.4 #1 0xb6e0ec30 in ?? () from /usr/lib/libQtCore.so.4 #2 0xb6e0f898 in ?? () from /usr/lib/libQtCore.so.4 #3 0xb6e0fbec in ?? () from /usr/lib/libQtCore.so.4 #4 0xb6e12f17 in QRegExp::indexIn(QString const&, int, QRegExp::CaretMode) const () from /usr/lib/libQtCore.so.4 #5 0xb058fd96 in ?? () from /usr/lib/libkmailprivate.so.4 #6 0xb059108a in ?? () from /usr/lib/libkmailprivate.so.4 #7 0xb058b652 in ?? () from /usr/lib/libkmailprivate.so.4 #8 0xb0572ce5 in ?? () from /usr/lib/libkmailprivate.so.4 #9 0xb05739c7 in ?? () from /usr/lib/libkmailprivate.so.4 #10 0xb04c4c1f in ?? () from /usr/lib/libkmailprivate.so.4 #11 0xb05607f9 in ?? () from /usr/lib/libkmailprivate.so.4 #12 0xb056298e in ?? () from /usr/lib/libkmailprivate.so.4 #13 0xb0557833 in KMail::AccountManager::processNextCheck(bool) () from /usr/lib/libkmailprivate.so.4 #14 0xb0558318 in KMail::AccountManager::singleCheckMail(KMAccount*, bool) () from /usr/lib/libkmailprivate.so.4 #15 0xb055874e in KMail::AccountManager::checkMail(bool) () from /usr/lib/libkmailprivate.so.4 #16 0xb071b358 in KMMainWidget::slotCheckMail() () from /usr/lib/libkmailprivate.so.4 #17 0xb074189f in KMMainWidget::qt_metacall(QMetaObject::Call, int, void**) () from /usr/lib/libkmailprivate.so.4 #18 0xb6ee0864 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/libQtCore.so.4 #19 0xb6ee0d41 in QMetaObject::activate(QObject*, QMetaObject const*, int, int, void**) () from /usr/lib/libQtCore.so.4 #20 0xb650a0c5 in QAction::triggered(bool) () from /usr/lib/libQtGui.so.4 #21 0xb650b6f2 in QAction::activate(QAction::ActionEvent) () from /usr/lib/libQtGui.so.4 #22 0xb699e8e0 in QToolButton::nextCheckState() () from /usr/lib/libQtGui.so.4 #23 0xb68b5aa7 in ?? () from /usr/lib/libQtGui.so.4 #24 0xb68b5d86 in QAbstractButton::mouseReleaseEvent(QMouseEvent*) () from /usr/lib/libQtGui.so.4 #25 0xb699eded in QToolButton::mouseReleaseEvent(QMouseEvent*) () from /usr/lib/libQtGui.so.4 #26 0xb6567bac in QWidget::event(QEvent*) () from /usr/lib/libQtGui.so.4 #27 0xb68b3c40 in QAbstractButton::event(QEvent*) () from /usr/lib/libQtGui.so.4 #28 0xb69a183c in QToolButton::event(QEvent*) () from /usr/lib/libQtGui.so.4 #29 0xb65108fc in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4 #30 0xb6518bbb in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4 #31 0xb740d521 in KApplication::notify(QObject*, QEvent*) () from /usr/lib/libkdeui.so.5 #32 0xb6eca32e in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQtCore.so.4 #33 0xb6517bdc in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&) () from /usr/lib/libQtGui.so.4 #34 0xb658880a in ?? () from /usr/lib/libQtGui.so.4 #35 0xb6587d7e in QApplication::x11ProcessEvent(_XEvent*) () from /usr/lib/libQtGui.so.4 #36 0xb65b2b68 in ?? () from /usr/lib/libQtGui.so.4 #37 0xb48184c2 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #38 0xb481bd98 in ?? () from /usr/lib/libglib-2.0.so.0 ---Type <return> to continue, or q <return> to quit--- #39 0xb481bebe in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #40 0xb6ef6011 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #41 0xb65b229a in ?? () from /usr/lib/libQtGui.so.4 #42 0xb6ec898d in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #43 0xb6ec8dd9 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #44 0xb6ecb270 in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4 #45 0xb6510774 in QApplication::exec() () from /usr/lib/libQtGui.so.4 #46 0x0804b546 in _start () (gdb) In every stack trace I viewed, the line marked '#4' and below were pretty much the same. Only the few lines at the top (of the stack) varied slightly, some times with, some times without the 'QChar::toLower()' entry. Does this stack trace maybe help already to identify the problem? I have read the "How to create useful crash reports" guidelines, but I could not find any debug related packages for kmail, kontact and/or kdepim in the OpenSuSE repositories. If someone can point me to the required debug packages, I'd be glad to recreate the stack trace and whatever else is required with those installed.
Comment 1 Denis Kurz 2016-09-24 19:22:09 UTC
This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present? If noone confirms this bug for a Framework-based version of kontact (version 5.0 or later, as part of KDE Applications 15.08 or later), it gets closed in about three months.
Comment 2 DecentM 2016-11-16 16:34:41 UTC
The same (or very similar) thing is happening to me as well on Kmail 5.3.3 on Manjaro. Whenever I try to send a message with attachments (or a signed e-mail), the UI's responsiveness slows to a crawl while CPU usage jumps up to about 75% on my quad-core system. Whenever another window is in focus, the system becomes usable again until Kmail gets focus. This stops after a while, and the message can be sent like any other.