GNOME Bugzilla – Bug 733877
Parse attachments on demand, not on message open
Last modified: 2015-08-19 14:10:28 UTC
* Evolution 3.12.4 on Fedora 20 with Gnome 3.12 Copr * One crashing email was sent using Zimbra (X-Mailer: Zimbra 8.0.2_GA_5569 (ZimbraWebClient - FF28 (Linux)/8.0.2_GA_5569)) * The other was sent using Outlook 2013 (<meta name="Generator" content="Microsoft Word 15 (filtered medium)">) * No message body is displayed on either before the freeze. * Asked the same person to send an empty CSV (open Excel with a blank sheet, save as CSV) the same way (attached the same way via Outlook) and didn't crash (in the source, the Base64 of the file is "DQo=" without quotation marks). In this case, there is the option to view inline - is this something to do with Evolution trying to parse CSV for inline display, then crashing on its content? * Content structure from more recent crashing email: Content-Type: multipart/mixed; boundary="[boundary identifier]" MIME-Version: 1.0 --[boundary identifier] Content-Type: multipart/alternative; boundary="[boundary identifier]" --[boundary identifier] Content-Type: text/plain; charset="us-ascii" [ASCII text] --[boundary identifier] Content-Type: text/html; charset="us-ascii" [beatiful, well-formed, semantic Outlook HTML...] --[boundary identifier]-- --[boundary identifier] Content-Type: application/octet-stream; name="[filename].csv" Content-Description: [filename].csv Content-Disposition: attachment; filename="[filename].csv"; size=840311; creation-date="Mon, 28 Jul 2014 15:28:16 GMT"; modification-date="Mon, 14 Jul 2014 14:27:04 GMT" Content-Transfer-Encoding: base64 [Base64-encoded file] --[boundary identifier]--
If it freezes, could you please provide a stacktrace via gdb? Also see https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces
Thanks for a bug report. I'd guess it's bug #724909, which was fixed for 3.12.7+. Could you update to it and retest, eventually get a backtrace of the frozen evolution, as Andre asked for, please? It'll help to identify the cause of the freeze. Thanks in advance.
No, unfortunately not fixed, still present on 3.12.9 (3.12.9-1.fc21 on Fedora 21). I haven't had the chance to do a backtrace yet, but testing one email with a CSV, it pegged one CPU core at 100% for about 15 minutes with no significant increase in memory use, then segfaulted. Dmesg: evolution-sourc[9491]: segfault at 7fd3121e8bb0 ip 00007fd32995b4bc sp 00007fff06c93380 error 7 in libglib-2.0.so.0.4200.1[7fd3298d7000+137000]
Here is a a stack backtrace. Perhaps the problem is in rendering large .CSV files? (I've updated my debuginfo so that next time I can pull in line numbers within the WebKit code) evolution-3.12.9-1.fc21.x86_64
+ Trace 234824
Thanks fro the update, no need to install the WebKitGtk debug information, it's awfully large. You are right with the large CSV file rendering, the backtraces matches the one at bug #743926, thus I mark this as a duplicate of it. *** This bug has been marked as a duplicate of bug 743926 ***
*** Bug 748065 has been marked as a duplicate of this bug. ***
I'm reopening this, after a consensus at bug #743926. Evolution shouldn't parse attachments on message open, but rather on demand, when the content is requested. Let's depend on WebKit2 port, to not write the change multiple times.
bug #705705 comment #1 contains a test message, which can reproduce the same backtrace as that yours. The difference is that the test message is a text/plain message with no attachments.
I realized there is no need to wait for a WebKit2 port, thus let's do this straight away. This will work only for attachments and only for those which are not marked to be displayed inline. The trick is that the attachment is read and formatted only after it is expanded for the first time, thus usual CSV attachments are kept untouched when the message is selected to be viewed. Created commit cecc70d in evo master (3.17.3+) Created commit 3298d49 in evo gnome-3-16 (3.16.3+)
*** Bug 750008 has been marked as a duplicate of this bug. ***
(In reply to Milan Crha from comment #7) > I'm reopening this, after a consensus at bug #743926. > > Evolution shouldn't parse attachments on message open, but rather on demand, > when the content is requested. I still think we should have an upper (either time or size) limit. Either my machine is awefully slow or evolution is not the right app to open megabytes-long text attachments.
Another issue arises when you request the attachment to be shown inline, evolution hangs trying to open such attachment, and on next open it remembers that it should be expanded, no longer allowing the email to be (easily) opened.
(In reply to Nguyen Thai Ngoc Duy from comment #11) > I still think we should have an upper (either time or size) limit. Either my > machine is awefully slow or evolution is not the right app to open > megabytes-long text attachments. Note it is stuck in the main thread, in a WebKitGTK code. The side intent of the use of the WebKitGTK was to not need the size limit, which used to be there in the past, when GtkHTML was used for preview rendering. (In reply to Ángel from comment #12) > Another issue arises when you request the attachment to be shown inline, > evolution hangs trying to open such attachment, and on next open it > remembers that it should be expanded, no longer allowing the email to be > (easily) opened. When you expand it inline is a known thing. I am not aware of the evolution to remember in any way which attachments were expanded and which not. You probably moved only away from a message to a place which didn't re-render another message, thus the setting of expanded attachments was "remembered" due to reuse of the in-memory data, which gets discarded only if another message is parsed. I tried that, but I'm not able to reproduce it this way.
One follow-up change. It could sometimes happen that for example image attachments couldn't be expanded, due to the WebKit DOM element not being available yet. I made a follow-up change to not rely on the WebKit DOM at all. Created commit 7de1b17 in evo master (3.17.3+) Created commit 1d0931d in evo gnome-3-16 (3.16.3+)
I can't try these patches until next week (and even then I may fail to back port to 3.12, e-d-s as a system dependency makes it hard to jump straght to latest evo), but does evolution still freeze on big text attachments after these changes if I expand them? There's no sign of "big attachments, careful" in the attachment dropdown menu if I remember correctly.
Tested 3298d49 (on 3.12.11). Expanding a 1.2MB text attachment blocks evolution for 23 seconds on i3-3217U CPU @ 1.80GHz. This is not an artificial attachment just to stress test evolution. I receive many of those mails. My biggest problem is there's no sign around the drop down list to warn me "big attachments, UI freeze ahead".
Err, this change causes crashes [1] in WebCore::extractDirectionAndWritingMode() when opening message list digest email (it contains multiple expanded mail attachments). [1] https://bugzilla.redhat.com/show_bug.cgi?id=1231591 The detailed backtrace with webkitgtk3-2.4.9-1.fc22 is:
+ Trace 235353
Thread 1 (Thread 0x7f69235c5a40 (LWP 15777))
I fixed the crash with the below change: Created commit 74a97a1 in evo master (3.17.91+)