I received a spam message with an RTF attachment. When I click it, evolution fully locks up. I have to kill it. Worse, if I right click this message, the popup menu shows, and evolution starts to render the message, then the whole desktop locks up. I cannot reproduce on Fedora 20 with the Gnome 3.12 update, but I think as long as Gnome 3.10 is the default on Fedora 20, a fix for 3.10 should be provided.
Thanks for a bug report and data. I'm pretty sure it's a fix for an upstream bug report [1], which makes this work in 3.12.x. The backport is quite problematic, due to API changes in evolution-data-server. Rather than try to cook anything for 3.10, just get rid of /usr/lib/evolution/3.10/modules/module-text-highlight.so alternatively in /usr/lib64/... [1] https://bugzilla.gnome.org/show_bug.cgi?id=724909
*** Bug 1090203 has been marked as a duplicate of this bug. ***
(In reply to Milan Crha from comment #2) > Thanks for a bug report and data. I'm pretty sure it's a fix for an upstream > bug report [1], which makes this work in 3.12.x. The backport is quite > problematic, due to API changes in evolution-data-server. Rather than try to > cook anything for 3.10, just get rid of > /usr/lib/evolution/3.10/modules/module-text-highlight.so > alternatively in /usr/lib64/... > > [1] https://bugzilla.gnome.org/show_bug.cgi?id=724909 Yep, that worked. Thanks.
(In reply to Milan Crha from comment #2) > just get rid of > /usr/lib/evolution/3.10/modules/module-text-highlight.so > alternatively in /usr/lib64/... I confirm it prevents the deadlock. If that's your recommended workaround for F20, how about building an updated evolution package that doesn't contain the file, allowing everyone to benefit from your suggested workaround?
(In reply to Kai Engert (:kaie) from comment #5) > If that's your recommended workaround for F20, how about building an updated > evolution package that doesn't contain the file, allowing everyone to > benefit from your suggested workaround? Yeah, I agree. If it doesn't work, don't ship it.
(In reply to Bojan Smojver from comment #6) > If it doesn't work, don't ship it. It's not accurate. The module is available since 3.6.0 and only recently had been discovered this problem with it. I can disable/remove it in a build, but I do not think it's really needed, because it had been used for more than a year. The upstream bug report contains more details. I'll provide a build without the module, if there will be filled more issues with it.
I'm building Evolution with more recent upstream fix, backported to Fedora 20. Evolution doesn't lock up any more, but please note that the large message processing can take its time anyway. The difference is that the Evolution is not idle during this processing, but it uses significant part of CPU.
evolution-3.10.4-4.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/evolution-3.10.4-4.fc20
evolution-3.10.4-4.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
This bug is back in evolution-3.12.8-1.fc21.i686. Just had 100% CPU utilisation and Evo unresponsive on an e-mail with a CSV attachment. Removing /usr/lib/evolution/3.12/modules/module-text-highlight.so and restarting Evo fixed things.
That's quite surprising to me. What is your highlight package version, please? Would it be possible to share the email, or its size and structure, for reproducer, please? You can even send it compressed only to me, for testing purposes, just name the bug number (or link) in the message subject, thus I'd not overlook it in my spam folder).
(In reply to Milan Crha from comment #12) > That's quite surprising to me. What is your highlight package version, > please? highlight-3.18-4.fc21.i686 > Would it be possible to share the email, or its size and structure, > for reproducer, please? You can even send it compressed only to me, for > testing purposes, just name the bug number (or link) in the message subject, > thus I'd not overlook it in my spam folder). I will have to ask permission before sending it to you (cannot attach it here for sure), because it is a work related e-mail. The attachment is a CSV file, where the first line contains comma separated column titles. Other lines contain data, consisting of alphanumeric characters, dots, dashes, asterisks etc., also comma delimited.
One more details: the attachment is 1.1 MB in size, if it matters.
Created attachment 964448 [details] anonymize.c I wrote this little utility to anonymize texts. I didn't try it for messages, but it may work as a plain text file, thus simply save the message (yes, the size matters) and run the 'anonymize p' on each part content, that is, if your message content looks like: Received: .... Date: ... Subject: ... <...many various headers...> Content-type: multipart/mixed; boundary="=-Ek1Ok27RCk/RdFRcOkXO" --=-Ek1Ok27RCk/RdFRcOkXO Content-Type: text/plain Content-Transfer-Encoding: 7bit Some message, text here. --=-Ek1Ok27RCk/RdFRcOkXO Content-Disposition: attachment; filename="file.cvs" Content-Type: text/plain; name="file.cvs"; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit some CVS content here --=-Ek1Ok27RCk/RdFRcOkXO-- Then get the text which should be anonymized (the headers should stay as they are, at least those beginning with Content-*), save them to a file and run them through the anonymize binary. Say I saved the content into a.txt, the I run: $ cat a.txt | anonymize p >b.txt and then I replace the text from a.txt with the one in b.txt in the saved email. You may even try to import the resulting message and check whether the freeze can be reproduced with that anonymized version.
OK, thanks. I may try that. In the meantime, with /usr/lib/evolution/3.12/modules/module-text-highlight.so still removed, I did Ctrl+U on the message. 100% CPU utilisation, Evo locked up. In other words, both the source window and main window are not responding to mouse clicks. So, maybe it's some other problem?
(In reply to Bojan Smojver from comment #16) > So, maybe it's some other problem? It can be. Please get the backtrace with command like this: $ 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).
Sorry for not responding to your debugging suggestions for a while. Just didn't find time to do it. What I did learn today is that it is that particular message (which I cannot share) that is causing the hang. I got another similar e-mail recently and no problem with it. So, there must be something that upsets the code that is supposed to be parsing this.
OpenSuSE 13.2 32 bit Evolution 3.12.9-4.15 I encountered also 'evolution unresponsive' and 'slow desktop'. It happens on any email that has Q-encoded (http://tools.ietf.org/html/rfc2047) headers like this: =?utf-8?q?this=20is=20some=20text?= Evolution hangs, once you click on such an email (left click or right click). I can provide an example email if needed.
(In reply to Marius GARBEA from comment #19) > I can provide an example email if needed. Having a test message which would reproduce the issue would be appreciated, especially as you see it with more recent evolution, 3.12.9.
Correction: the email that makes evolution unresponsive had (in my case): * (very) long, Q-encoded Subject - 111 lines with a total of 8395 characters * long Body - 7593 lines with a total of 2510587 characters I have created 2 emails out of it: one having the long Q-encoded subject and a tiny body, and the other having a tiny subject and the original body. It turned out that evolution issue is triggered by emails with long body.
Created attachment 994386 [details] sample (annonymized) email In addition to comment #21, here's a sample email
Created attachment 994394 [details] screenshot of evlution trying to display email with long body In addition to comment #21, here's a screenshot of evolution when 'unresponsive'. On my machine (an old Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz) it takes about 30 seconds to display the contents.
Thanks for the email. Your issue is different from the initial one, you face: https://bugzilla.gnome.org/show_bug.cgi?id=743926
I noticed a similar thing, with a 500K CSV attachment. I cannot share the actual CSV file or mail (confidential), but I'll try to do some tests with various CSV attachments to see if I can trigger this. In the meantime, I'll attach a backtrace as described in Comment #17. System info: Fedora 21 Evolution: evolution-3.12.11-1.fc21.x86_64 Cheers, Steven
Created attachment 1023528 [details] Backtrace from Evolution hanging on large CSV attachment Here's the backtrace from my evolution-3.12.11-1.fc21.x86_64 hanging on a mail with a large CSV attachment.
(In reply to Steven Bakker from comment #26) > Created attachment 1023528 [details] > Backtrace from Evolution hanging on large CSV attachment Your backtrace (pasted below for easier searching) matches: https://bugzilla.gnome.org/show_bug.cgi?id=743926 Thread 1 (Thread 0x7f5b2e5faa40 (LWP 18333)): #0 0x000000307cf37780 in WebCore::Style::attachRenderTree(WebCore::Element&, WTF::PassRefPtr<WebCore::RenderStyle>) () at /lib64/libwebkitgtk-3.0.so.0 #1 0x000000307cf38a20 in WebCore::Style::attachChildren(WebCore::ContainerNode&) () at /lib64/libwebkitgtk-3.0.so.0 #2 0x000000307cf37058 in WebCore::Style::attachRenderTree(WebCore::Element&, WTF::PassRefPtr<WebCore::RenderStyle>) () at /lib64/libwebkitgtk-3.0.so.0 #3 0x000000307cf38a20 in WebCore::Style::attachChildren(WebCore::ContainerNode&) () at /lib64/libwebkitgtk-3.0.so.0 #4 0x000000307cf37058 in WebCore::Style::attachRenderTree(WebCore::Element&, WTF::PassRefPtr<WebCore::RenderStyle>) () at /lib64/libwebkitgtk-3.0.so.0 #5 0x000000307cf38a20 in WebCore::Style::attachChildren(WebCore::ContainerNode&) () at /lib64/libwebkitgtk-3.0.so.0 #6 0x000000307cf37058 in WebCore::Style::attachRenderTree(WebCore::Element&, WTF::PassRefPtr<WebCore::RenderStyle>) () at /lib64/libwebkitgtk-3.0.so.0 #7 0x000000307cf3aad7 in WebCore::Style::resolveTree(WebCore::Element&, WebCore::Style::Change) () at /lib64/libwebkitgtk-3.0.so.0 #8 0x000000307cf3c552 in WebCore::Style::resolveTree(WebCore::Document&, WebCore::Style::Change) () at /lib64/libwebkitgtk-3.0.so.0 #9 0x000000307c7c5e44 in WebCore::Document::recalcStyle(WebCore::Style::Change) () at /lib64/libwebkitgtk-3.0.so.0 #10 0x000000307c7c6daa in WebCore::Document::updateStyleIfNeeded() () at /lib64/libwebkitgtk-3.0.so.0 #11 0x000000307c7c9689 in WebCore::Document::finishedParsing() () at /lib64/libwebkitgtk-3.0.so.0 #12 0x000000307ca28d0e in WebCore::HTMLDocumentParser::prepareToStopParsing() () at /lib64/libwebkitgtk-3.0.so.0 #13 0x000000307ca253c9 in WebCore::HTMLDocumentParser::finish() () at /lib64/libwebkitgtk-3.0.so.0 #14 0x000000307cbae522 in WebCore::DocumentWriter::end() () at /lib64/libwebkitgtk-3.0.so.0 #15 0x000000307cba3460 in WebCore::DocumentLoader::finishedLoading(double) () at /lib64/libwebkitgtk-3.0.so.0 #16 0x000000307cb8c179 in WebCore::CachedResource::checkNotify() () at /lib64/libwebkitgtk-3.0.so.0 #17 0x000000307cb873e8 in WebCore::CachedRawResource::finishLoading(WebCore::ResourceBuffer*) () at /lib64/libwebkitgtk-3.0.so.0 #18 0x000000307cbfac49 in WebCore::SubresourceLoader::didFinishLoading(double) () at /lib64/libwebkitgtk-3.0.so.0 #19 0x000000307d459f19 in WebCore::readCallback(_GObject*, _GAsyncResult*, void*) () at /lib64/libwebkitgtk-3.0.so.0 #20 0x000000307745ddaa in async_ready_callback_wrapper () at /lib64/libgio-2.0.so.0 #21 0x00000030774824cb in g_task_return_now () at /lib64/libgio-2.0.so.0 #22 0x00000030774824e9 in complete_in_idle_cb () at /lib64/libgio-2.0.so.0 #23 0x0000003122e497fb in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 #24 0x0000003122e49b98 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0 #25 0x0000003122e49ec2 in g_main_loop_run () at /lib64/libglib-2.0.so.0 #26 0x00000030785ec635 in gtk_main () at /lib64/libgtk-3.so.0 #27 0x000000000040389d in main ()
Ack. Apologies for polluting this bug thread.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.