GNOME Bugzilla – Bug 339135
formatting of pdf-attachments fills all available RAM and SWAP
Last modified: 2010-12-14 15:31:32 UTC
From: Bernhard Kleine <bbfk@gmx.net> To: submit@bugzilla.ximian.com X-Mailer: bug-buddy 2.14.0 Subject: formatting of pdf-attachments fills all available RAM and SWAP Distribution: Debian testing/unstable Package: Evolution Priority: Normal Version: GNOME2.14.0 unspecified Gnome-Distributor: Debian Synopsis: formatting of pdf-attachments fills all available RAM and SWAP Bugzilla-Product: Evolution Bugzilla-Component: Mailer Bugzilla-Version: unspecified Description: Description of Problem: Twice I have sent PDF attachments (larger than 10 Mb) to addresses which did not exist or accept that large mails. With some comment by the mail-server the mail was sent back. Evolution 2.4.1 tried to format the mail, but failed and started to use any availabel RAM and SWAP space. The system started to swap continously and was no longer usable. Steps to reproduce the problem: 1. Sent a mail with a larger PDF attachment to an existing mail server but to an non-existent user on that system. 2. Open the reply from mail agent. Evolution shows (Formatting mail....) 3. Using system monitor could can see the memory usage gradually to increase to 100%, afterwards the swap space get used, too. 4. After some activity with very much reduced keyboard reactivity (may be 15 minutes or less) evolution is stopped. Actual Results: Program crashes while formatting Expected Results: even 10 Mb PDF attachements should be properly formatted, the system has 780 MB RAM and 500 MB Swap-space. How often does this happen? With every large returned PDF-Attachment. Additional Information: -- Bernhard Kleine mail bbfk@gmx.net linux-user Nr. 411598 **************************************** PGP-Key PGP-Fingerprint: 0x6C1D9C2A 3161 A9E2 B661 A242 D9AF 61BF C842 4D18 6C1D 9C2A **************************************** ------- Bug created by bug-buddy at 2006-04-20 09:16 -------
can you attach a sample message that got sent back to you? I need the exact message that the smtp server sent back in case it changed Content-Type or other headers.
Created attachment 63990 [details] Head of return message the complete message still resides at gmx since I do not dare to download it to my own computer. all the best, bernhard
I have sorted out some issues: mime-type: Their is a bug (#6577) in the shared-mime-info which mixes up mime-types. The pdf-files I sent were errorneously taken as text/plain instead of application/pdf. In the freedesktop mailing list I was told to raise the priority of PDF to 60 (/usr/share/mime/packages/freedesktop.org.xml) which solved this issue. evolution: Again, I then send a mail to a fake addres with a large pdf-attachment. This time evolution _could_ manage the file and showed (still as text) the whole pdf file. I still wonder why evolution needs to fill half of my swap (230 MB) while formatting 7MB?!. Which helper application needs this much space? I think that the problem with regard to usability seems to be solved, the memory usage should worry you. Bernhard
Content-Type: text/plain; name=KeineHeilungdurchGene_060203.pdf; charset=us-ascii reopening as requested information has been provided.
*** Bug 587406 has been marked as a duplicate of this bug. ***
Mattew: are you sure that bug #587406 is a duplicate? I encountered that bug while _composing_ an e-mail, not while reading it, so the attachment does not need to be shown at all.
Mattew, ping! I do not want the other bug to stay here until this is fixed, and only then discover that it's a separate bug.
(In reply to comment #7) > Mattew, ping! I do not want the other bug to stay here until this is fixed, and > only then discover that it's a separate bug. I tried with actual git master and it works fine for me, the file is attached as an attachment, not as a text in the message body. As long as you'll not do a typo then it may be fine. The new code (since 2.30 or so) also has a checking for "too large messages" and avoids format them, to prevent this kind of issue. It's not a solution, it's just a workaround until the WebKit will reach evolution, where we hope in getting this fixed with it, by replacing mostly unmaintained GtkHTML, which is used in evolution today. -------------------------------------------------------------------------------- Similar applies for the initial bug report here. I sent a 4.2 MB pdf file to a non-existent address as a text/plain attachment suggested to be shown inline. Returned error email contained a message as an attachment, and expanding it shows the actual body of it, but for the inline "text" attachment is used the "Evolution cannot render this email as it is too large to process. You can view it unformatted or with an external text editor." message to prevent this bug. Thus I suppose this to be fixed, and I'm marking this as a duplicate of the bug where this functionality was added. *** This bug has been marked as a duplicate of bug 337439 ***