Bug 110574

I think it should display those emails. But it shouldn't crash :-)

Can you give us a backtrace of your crash, so that we can solve the problem?

On Saturday 13 August 2005 04:04, Thiago Macieira wrote:
[bugs.kde.org quoted mail]

How ? Do i have to recompile it with debug options turned on ?

If i start kmail as standalone app with --nofork, the crash only results in a 
popup with "The application KMail (kmail) crashed caused the signal 11 
(SIGSEGV)" and a very short message in the stdout:

*** KMail got signal 11 (Crashing)
KCrash: Application 'kmail' crashing...

In that dialog box, you should see a second tab called "Backtrace". Click 
it and paste the results here.

Hi Thiago,

> In that dialog box, you should see a second tab called "Backtrace". Click
> it and paste the results here.


I know what you mean, but this one has only one "General" tab.
I've installed gdb to be sure it does'nt check for it, but it makes no 
difference.

Your sure it's not posible to disable it during compile time ?

Hi Thiago,

By the way, when i am monitoring my memory usage during the crash, my kmail 
proces is getting bigger and bigger, round the 500Mb it crashed. I think it's 
killed by the kernel, and that's why i don't have a backtrace.

I think the only solution is not to load/show a big email at ones or to give a 
download option.

Unfortunately, that's a border case. KMail isn't allocating that memory all at once, which means it would have to watch its memory consumption. There's no way to tell what limit to impose...

As for being killed by the kernel, I am not sure this is the case. If it were, you wouldn't be seeing the Crash Handler dialog at all, and the signal would have been SIGKILL, not SIGSEGV.

This still looks like a bug, but without a backtrace it is not easy to reproduce. Maybe I'll mail myself 80MB... is that 80MB body, or does it include attachments?

Hi Thiago,

> Unfortunately, that's a border case. KMail isn't allocating that memory all
> at once, which means it would have to watch its memory consumption. There's
> no way to tell what limit to impose...


True. There's no way to make a nice solution for this. Maybe a max memory or 
max message size setting is something.

By the way, why is a message of 80 Mb so large in memory ?

> As for being killed by the kernel, I am not sure this is the case. If it
> were, you wouldn't be seeing the Crash Handler dialog at all, and the
> signal would have been SIGKILL, not SIGSEGV.


If i enlarge my swapspace to 2Gb (my memory is 512Mb and my swap was 128Mb), 
the proces is growing till 1,5 Gb (with a 66Mb mail) and than it's stable. 
But nothing is responding anymore (swapspace on a laptop is not very 
vast :-)) so i still had to kill it my self.

About the Crash Handler dialog, sometimes it not shown. Most of the time it 
is.

> This still looks like a bug, but without a backtrace it is not easy to
> reproduce. Maybe I'll mail myself 80MB... is that 80MB body, or does it
> include attachments?


It's body text, with most lines not longer than 50 characters.

28MB is large enough to crash kmail for me...
I get a crash without a backtrace on KDE 3.5.0/KMail 1.9.1/Kontact 1.2 on FC4 (kde-redhat package) when trying to read an e-mail with a large patch included in the body. The symptoms seem that kmail eats CPU and RAM until swap is depleted, then it crashes without a crash dialog.

BTW, it seems bug# 107649 could be marked as a duplicate of this one.

This is a very serious issue that needs more attention.  KMail is evidently using some terribly inefficient data structure for message bodies.  Though it may not result in an OOM crash on most machines, even text message bodies of around 0.5-2 Mb can trigger bad behavior in the form of run-away resource usage and memory leaks.  This behavior can be observed *any* time Kmail touches a large message body.  (preview pane, composer, view source, etc.)  The transport doesn't matter.  Behavior is identical with mbox,maildir,imap,etc.

Here's a real-world example viewing a 2Mb text message (a cron job report):

At Kmail load time with 3 IMAP accounts:  86M VSZ, 31M RSS
View large message:  136M VSZ, 77M RSS
View large msg. source:  148M VSZ, 91M RSS

The UI blocks and kmail process CPU usage is maxed while the message is loading, even on subsequent views. (takes about 10-15s on an AMD64 3000 w/1Gb)

Now close, de-select or even delete the large message.  Memory usage does not drop at all, hence evidence of a leak.

Also, try pasting a large (1-4 Mb) text into composer.  Similar results will be observed.  After the paste finally completes, any time you attempt to scroll the text in composer, kmail will hang for quite some time with maxed CPU usage.

This bug is possibly also related in its root cause to the following:
88427, 95060, 107649, 110574, 119281

*** Bug 136561 has been marked as a duplicate of this bug. ***

*** Bug 142715 has been marked as a duplicate of this bug. ***

Pasting a backtrace from one of the duplicates.
One can see that the new operator fails because there is not enough memory left. I guess in other occasions, the OOM killer of Linux just silently kills KMail, so this is why some people here do not get the crash handler window.

 Using host libthread_db library "/lib/libthread_db.so.1". 
 [Thread debugging using libthread_db enabled] 
 [New Thread -1240672592 (LWP 17739)] 
 [New Thread -1283892320 (LWP 17755)] 
 [New Thread -1275499616 (LWP 17754)] 
 [New Thread -1267106912 (LWP 17753)] 
 [New Thread -1258714208 (LWP 17752)] 
 [KCrash handler] 
 #6  0xffffe410 in __kernel_vsyscall () 
 #7  0xb68547d0 in raise () from /lib/libc.so.6 
 #8  0xb6855ea3 in abort () from /lib/libc.so.6 
 #9  0xb6a013a0 in __gnu_cxx::__verbose_terminate_handler () 
    from /usr/lib/libstdc++.so.6 
 #10 0xb69fedc5 in std::set_unexpected () from /usr/lib/libstdc++.so.6 
 #11 0xb69fee02 in std::terminate () from /usr/lib/libstdc++.so.6 
 #12 0xb69fef3a in __cxa_throw () from /usr/lib/libstdc++.so.6 
 #13 0xb69ff37e in operator new () from /usr/lib/libstdc++.so.6 
 #14 0xb69ff45d in operator new[] () from /usr/lib/libstdc++.so.6 
 #15 0xb4fce226 in mem_alloc () from /opt/kde3/lib/libmimelib.so.1 
 #16 0xb4fd15ff in DwString::_replace () from /opt/kde3/lib/libmimelib.so.1 
 #17 0xb4fd2227 in DwString::append () from /opt/kde3/lib/libmimelib.so.1 
 #18 0xb4fd22d3 in DwString::append () from /opt/kde3/lib/libmimelib.so.1 
 #19 0xb4fb94f0 in DwBody::Assemble () from /opt/kde3/lib/libmimelib.so.1 
 #20 0xb4fbf45b in DwEntity::Assemble () from /opt/kde3/lib/libmimelib.so.1 
 #21 0xb51c61ef in KMMessage::asDwString () 
    from /opt/kde3/lib/libkmailprivate.so 
 #22 0xb51c9098 in KMMessage::asString () from /opt/kde3/lib/libkmailprivate.so 
 #23 0xb542cdbe in KMail::CachedImapJob::slotPutNextMessage () 
    from /opt/kde3/lib/libkmailprivate.so 
 #24 0xb5428fd7 in KMail::CachedImapJob::slotPutMessageResult () 
    from /opt/kde3/lib/libkmailprivate.so 
 #25 0xb542aaff in KMail::CachedImapJob::qt_invoke () 
    from /opt/kde3/lib/libkmailprivate.so 
 #26 0xb6cb967d in QObject::activate_signal () 
    from /usr/lib/qt3/lib/libqt-mt.so.3 
 #27 0xb77a4dae in KIO::Job::result () from /opt/kde3/lib/libkio.so.4 
 #28 0xb77ee7cd in KIO::Job::emitResult () from /opt/kde3/lib/libkio.so.4 
 #29 0xb7805cae in KIO::SimpleJob::slotFinished () 
    from /opt/kde3/lib/libkio.so.4 
 #30 0xb78063cd in KIO::TransferJob::slotFinished () 
    from /opt/kde3/lib/libkio.so.4 
 #31 0xb77ee3fa in KIO::TransferJob::qt_invoke () 
 from /opt/kde3/lib/libkio.so.4 
 #32 0xb6cb967d in QObject::activate_signal () 
    from /usr/lib/qt3/lib/libqt-mt.so.3 
 #33 0xb6cba2dd in QObject::activate_signal () 
    from /usr/lib/qt3/lib/libqt-mt.so.3 
 #34 0xb779fe1c in KIO::SlaveInterface::finished () 
    from /opt/kde3/lib/libkio.so.4 
 #35 0xb7804b95 in KIO::SlaveInterface::dispatch () 
    from /opt/kde3/lib/libkio.so.4 
 #36 0xb7815dca in KIO::SlaveInterface::dispatch () 
    from /opt/kde3/lib/libkio.so.4 
 #37 0xb77b471c in KIO::Slave::gotInput () from /opt/kde3/lib/libkio.so.4 
 #38 0xb77f4060 in KIO::Slave::qt_invoke () from /opt/kde3/lib/libkio.so.4 
 #39 0xb6cb967d in QObject::activate_signal () 
    from /usr/lib/qt3/lib/libqt-mt.so.3 
 #40 0xb6cba1e2 in QObject::activate_signal () 
    from /usr/lib/qt3/lib/libqt-mt.so.3 
 #41 0xb6ff3190 in QSocketNotifier::activated () 
    from /usr/lib/qt3/lib/libqt-mt.so.3 
 #42 0xb6cd7880 in QSocketNotifier::event () 
 from /usr/lib/qt3/lib/libqt-mt.so.3 
 #43 0xb6c5a547 in QApplication::internalNotify () 
    from /usr/lib/qt3/lib/libqt-mt.so.3 
 #44 0xb6c5b311 in QApplication::notify () from /usr/lib/qt3/lib/libqt-mt.so.3 
 #45 0xb7315e23 in KApplication::notify () from /opt/kde3/lib/libkdecore.so.4 
 #46 0xb6c4ee64 in QEventLoop::activateSocketNotifiers () 
    from /usr/lib/qt3/lib/libqt-mt.so.3 
 #47 0xb6c09874 in QEventLoop::processEvents () 
    from /usr/lib/qt3/lib/libqt-mt.so.3 
 #48 0xb6c71368 in QEventLoop::enterLoop () from /usr/lib/qt3/lib/libqt-mt.so.3 
 #49 0xb6c711fe in QEventLoop::exec () from /usr/lib/qt3/lib/libqt-mt.so.3 
 #50 0xb6c5a0ff in QApplication::exec () from /usr/lib/qt3/lib/libqt-mt.so.3 
 #51 0x08058c39 in main () 

Related to bug #75045, not sure if it is quite the same.

*** Bug 130894 has been marked as a duplicate of this bug. ***

*** Bug 143537 has been marked as a duplicate of this bug. ***

Backtrace from bug 143537 (sending 22 MB file):

 (no debugging symbols found) 
 Using host libthread_db library "/lib/libthread_db.so.1". 
 (no debugging symbols found) 
 [..]
 (no debugging symbols found) 
 [Thread debugging using libthread_db enabled] 
 [New Thread -1241495136 (LWP 3791)] 
 [New Thread -1281881200 (LWP 3912)] 
 [New Thread -1273488496 (LWP 3911)] 
 [New Thread -1265095792 (LWP 3910)] 
 [New Thread -1256703088 (LWP 3909)] 
 (no debugging symbols found) 
 [..]
 (no debugging symbols found) 
 [KCrash handler] 
 #9  0xb67ef4ca in memcpy () from /lib/libc.so.6 
 #10 0xb6eb8d5f in QGArray::duplicate () from /usr/lib/qt3/lib/libqt-mt.so.3 
 #11 0xb6eab4c2 in QCString::QCString () from /usr/lib/qt3/lib/libqt-mt.so.3 
 #12 0xb54f66fa in KMMessage::asString () from /opt/kde3/lib/libkmailprivate.so 
 #13 0xb54f89a1 in KMMessage::asSendableString () 
    from /opt/kde3/lib/libkmailprivate.so 
 #14 0xb5606142 in KMSender::doSendMsgAux () 
    from /opt/kde3/lib/libkmailprivate.so 
 #15 0xb5606878 in KMSender::sendProcStarted () 
    from /opt/kde3/lib/libkmailprivate.so 
 #16 0xb5609ce9 in KMSender::qt_invoke () from /opt/kde3/lib/libkmailprivate.so 
 #17 0xb6c073cd in QObject::activate_signal () 
    from /usr/lib/qt3/lib/libqt-mt.so.3 
 #18 0xb6c07a95 in QObject::activate_signal_bool () 
    from /usr/lib/qt3/lib/libqt-mt.so.3 
 #19 0xb56037ae in KMSendProc::started () from /opt/kde3/lib/libkmailprivate.so 
 #20 0xb5608db4 in KMSender::doSendMsg () from /opt/kde3/lib/libkmailprivate.so 
 #21 0xb5609e52 in KMSender::doSendQueued () 
    from /opt/kde3/lib/libkmailprivate.so 
 #22 0xb5605735 in KMSender::doSend () from /opt/kde3/lib/libkmailprivate.so 
 #23 0xb55af860 in KMComposeWin::slotContinueDoSend () 
    from /opt/kde3/lib/libkmailprivate.so 
 #24 0xb55b3304 in KMComposeWin::qt_invoke () 
    from /opt/kde3/lib/libkmailprivate.so 
 #25 0xb6c073cd in QObject::activate_signal () 
    from /usr/lib/qt3/lib/libqt-mt.so.3 
 #26 0xb6c07a95 in QObject::activate_signal_bool () 
    from /usr/lib/qt3/lib/libqt-mt.so.3 
 #27 0xb559339b in KMComposeWin::applyChangesDone () 
    from /opt/kde3/lib/libkmailprivate.so 
 #28 0xb5594d5e in KMComposeWin::slotComposerDone () 
    from /opt/kde3/lib/libkmailprivate.so 
 #29 0xb55b32e5 in KMComposeWin::qt_invoke () 
    from /opt/kde3/lib/libkmailprivate.so 
 #30 0xb6c073cd in QObject::activate_signal () 
    from /usr/lib/qt3/lib/libqt-mt.so.3 
 #31 0xb6c07a95 in QObject::activate_signal_bool () 
    from /usr/lib/qt3/lib/libqt-mt.so.3 
 #32 0xb578851b in MessageComposer::done () 
    from /opt/kde3/lib/libkmailprivate.so 
 #33 0xb57887be in MessageComposer::doNextJob () 
    from /opt/kde3/lib/libkmailprivate.so 
 #34 0xb5788805 in MessageComposer::slotDoNextJob () 
    from /opt/kde3/lib/libkmailprivate.so 
 #35 0xb57888e2 in MessageComposer::qt_invoke () 
    from /opt/kde3/lib/libkmailprivate.so 
 #36 0xb6c073cd in QObject::activate_signal () 
    from /usr/lib/qt3/lib/libqt-mt.so.3 
 #37 0xb6f410ce in QSignal::signal () from /usr/lib/qt3/lib/libqt-mt.so.3 
 #38 0xb6c23497 in QSignal::activate () from /usr/lib/qt3/lib/libqt-mt.so.3 
 #39 0xb6c2a823 in QSingleShotTimer::event () 
    from /usr/lib/qt3/lib/libqt-mt.so.3 
 #40 0xb6ba8647 in QApplication::internalNotify () 
    from /usr/lib/qt3/lib/libqt-mt.so.3 
 #41 0xb6ba94f9 in QApplication::notify () from /usr/lib/qt3/lib/libqt-mt.so.3 
 #42 0xb72661f2 in KApplication::notify () from /opt/kde3/lib/libkdecore.so.4 
 #43 0xb6b9d663 in QEventLoop::activateTimers () 
    from /usr/lib/qt3/lib/libqt-mt.so.3 
 #44 0xb6b57bd0 in QEventLoop::processEvents () 
    from /usr/lib/qt3/lib/libqt-mt.so.3 
 #45 0xb6bbf0e0 in QEventLoop::enterLoop () from /usr/lib/qt3/lib/libqt-mt.so.3 
 #46 0xb6bbef76 in QEventLoop::exec () from /usr/lib/qt3/lib/libqt-mt.so.3 
 #47 0xb6ba800f in QApplication::exec () from /usr/lib/qt3/lib/libqt-mt.so.3 
 #48 0x08058c12 in QWidget::setUpdatesEnabled () 
 #49 0xbf912ecc in ?? () 
 #50 0x00000001 in ?? () 
 #51 0x00000001 in ?? () 
 #52 0x00000000 in ?? () 

*** Bug 143780 has been marked as a duplicate of this bug. ***

Changing summary.

The runaway process is kio_imap4, it tries to grab memory until the system
starts to swap heavily and grinds to a halt. As a temporary fix I added
  ulimit -S -v [amount of system memory in kB]
  ulimit -S -m [0.8 x amount of system memory in kB]
to /etc/profile.d/limits.sh. With these settings KMail now at least bails
out gracefully without crashing; the e-mail still cannot be read though.
If you are using something other than Mandriva/bash, you may have to edit
different files.

P.S.
I do not consider 4MB a large attachment, and KMail should be able to deal
with it!

> When trying to load/preview an e-mail I recently received, which had more
> than ~30 attachments and was ~4MB in size, the system locked up completely
> after some initial disk activity. A system reset was then required.  I view
> this as critical - KMail must not bring the whole system down, even if the
> e-mail it receives is extremely large or complex.
>
> When trying to access the same e-mail on a different machine with more HW
> resources (but the same software setup), the system froze again for a few
> minutes with heavy disk activity, probably swapping, but then came back to
> life with the following message from KMail: 'Error while retrieving
> information on the structure of a message.' 'The process for the
> imap://imap228.herald.ox.ac.uk protocol died unexpectedly.'
>
> A different e-mail from the same sender, so probably sent from the same
> client and having the same internal structure, but only with 8 attachments
> and ~2MB size, did not cause any problems.

This may be fixed for 3.5.7, see:

http://lists.kde.org/?l=kde-commits&m=117153685725476&w=2
http://lists.kde.org/?l=kde-commits&m=117158032004939&w=2

>This may be fixed for 3.5.7, see: 
Someone who is using SVN 3.5 branch should check if sending mails with large attachments works better now.

BTW, I think the forwardport to trunk is partially missing, I only found

>SVN commit 633984 by dfaure:

>Forwardport parts of the 2nd-memory-reduction patch.

But where is the 1st patch?

*** Bug 162862 has been marked as a duplicate of this bug. ***

*** Bug 167584 has been marked as a duplicate of this bug. ***

*** Bug 174669 has been marked as a duplicate of this bug. ***

*** Bug 176529 has been marked as a duplicate of this bug. ***

*** This bug has been confirmed by popular vote. ***

*** Bug 200476 has been marked as a duplicate of this bug. ***

Same problem here. KMail 1.12.3 (KDE 4.3.3) eats tons of memory after displaying body of few messages, each containing about 10 x 1.5 MB jpg attachments. Images are not displayed in message body - only list of attachments. It is IMAP account.

Potentially related bugs:
bug #75045
bug #201083

*** Bug 201083 has been marked as a duplicate of this bug. ***

*** Bug 220650 has been marked as a duplicate of this bug. ***

I am experiencing this bug with kmail 4.4.2 and POP3 when trying to preview (preview window on the right side) an E-Mail with an attached image of around 550kb size. This is quite annoying because I could not save the contents of the image because every time I tried Kmail crashed.

However I found out that viewing the message after double clicking does NOT crash Kmail. I only had to disable preview mode in Settings > Appearance > Layout and view the message by doubleclicking.

Funnily enough it is working now after resizing the preview area. Maybe, in my special case, this is related to the image resizing function as the image is too big to fit into the preview area. 

I found out that there is a size of the image which can lead to an endless resizing loop. 
If the image is a little bit wider than the preview area WITH VERTICAL scrollbar it will be resized to fit to the preview area without scrollbar. After resizing the width my special image completely fits into the preview area so that no vertical scrollbar is needed, too. Afterwards KMail seems to think that the image does not need to be resized because it fits into the width of the preview area without vertical and horizontal scrollbar. So Kmail disables the resizing. After that everything continues from the beginning and KMail is not longer usable. 

Maybe there is a problem with width calculation and it is only based on the width of the preview area without vertical scrollbar.

I do not know if this i related to the original bug report any longer. If it is not just let me know and I will file a new bug report.

*** Bug 286471 has been marked as a duplicate of this bug. ***

Thank you for your report. Kmail1 is currently unmaintained and the code has changed sufficiently in Kmail2 so the backtraces are not really useful anymore. Should you experience the same crash in Kmail 4.8.5 or later, please open a new report for Kmail2. Thank you for your understanding