GNOME Bugzilla – Bug 766866
Regression on prefer-plain plugin [Bug 686278] and multipart MIME
Last modified: 2016-06-08 06:40:11 UTC
If prefer-plain -plugin is enabled some multipart mime messages (at least with IMAP) get stuck on Parsing and do not display anything or show garbage. I think it's a regression on fixed Bug 686278 https://bugzilla.gnome.org/show_bug.cgi?id=686278 Disabling prefer-plain and clearing affected files from local cache showed the message normally with attachments. This on Ubuntu Xenial 16.04 64 bit with stock evolution 3.18.5.2-0ubuntu1
Thanks for a bug report. By any chance, do you have a test message for it, please? I tried with the test message from the bug #686278 on the current development version of the evolution (3.21.2) and it opened that message without any issue. In case the message contains too much private information, feel free to send it only to me, as a zipped-attachment, to my bugzilla email address, only name this bug report in the subject, otherwise I'd overlook it in my spam folder. Thanks in advance.
I will look for an email (with this problem) that does not contain personal info. And I will try to get this done inside 24 hours.
Created attachment 328558 [details] Smaller sanitized version of the problem mail
Original email was over 19MiB in size (somewhat large pdf files). I cannot reproduce the problem at the moment. 1. Re-enabled prefer-plain 2. added test email and original again on the imap server 3. evolution works fine This got me thinking that this could be a race condition problem. Because I've run into this problem with smaller emails also (not only size matters). This has happened about 10 times in last month (when I installed new ubuntu on a new machine). Old machine with evolution (version what Ubuntu trusty comes with) never had this problem. Symptons exhibited looked like the old prefer-plain problem and disabling that plugin + removing cache file (that was full of '@@@@@@@@@@') resolved the issue for this particular email. I'll add more info if I can think of a way to reproduce this problem systematically
(In reply to netti from comment #4) > Original email was over 19MiB in size (somewhat large pdf files). > > ... > > Symptons exhibited looked like the old prefer-plain problem and disabling > that plugin + removing cache file (that was full of '@@@@@@@@@@') resolved > the issue for this particular email. Maybe that's it, a very large text mail, which webkit tries to parse. It could happen that sometimes the webkit is quick and sometimes not, thus the prefer-plain idea can be only a matter of luck. Those '@@@' might be that the message was received broken. That had been discussed in bug #761096, while I think your issue is caused just by it. You can figure it out if you grab a backtrace of the stuck evolution with the below gdb command, only make sure you'll have installed also debugging information for the evolution itself and the evolution-data-server (not necessarily for its dependencies), thus the backtrace will be usable. The command is: $ gdb --batch --ex "t a a bt" -pid=`pidof evolution` &>bt.txt Please check the bt.txt for any private information, like passwords, email address, server addresses,... I usually search for "pass" at least (quotes for clarity only).
I can now confirm, that prefer-plain is not affecting this bug. I think this is duplicate of bug #761096, but atm I have to wait to have enough time to try upstream newer version of evolution. I checked from git that the version I currently use does not have "UseMultiFetch" option, so I cannot confirm. Last email that was broken missed begining of the message (including headers etc) and only showed mimepart attachemt as text on body. *** This bug has been marked as a duplicate of bug 761096 ***