Created attachment 934042 [details] screenshot of evolution Description of problem: evolution hangs again
Created attachment 934043 [details] evolution backtrace
$ rpm -qa | grep evolution evolution-3.12.4-1.fc20.i686 evolution-debuginfo-3.12.4-1.fc20.i686 evolution-ews-3.12.4-1.fc20.i686 evolution-data-server-debuginfo-3.12.5-1.fc20.i686 evolution-data-server-3.12.5-1.fc20.i686 evolution-ews-debuginfo-3.12.4-1.fc20.i686
Thanks for a bug report. According to the backtrace the UI thread is blocked by the text highlight module, processing the selected message (see the screen-shot at comment #0 which it was). Could you disable the preview panel (Ctrl+M), or run evolution as: $ evolution --disable-preview -c mail and save the message, then either upload it here, or if it contains too much private information then just send it to me, with a subject mentioning this bug report, thus it'll not be lost in my spam folder, please? I'll try to reproduce it here. Could you also provide version of a 'highlight' package, please? A workaround would be to move away the text highlight module from evolution, which resides at: /usr/lib/evolution/3.12/modules/module-text-highlight.so renaming that file, or moving to another folder, will stop using the highlight utility.
$ rpm -q highlight highlight-3.18-1.fc20.i686
Created attachment 934288 [details] problem message
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Thanks for the message. I can reproduce it with it too. The 7.5MB CSV attachment makes it some time to process it both through highlight, but also through webkit itself, which makes evolution unresponsive for couple seconds (less than 30 seconds), with a high CPU usage. If I upgrade to highlight 3.18-1, then I can reproduce the hang, there is no CPU usage and evolution is waiting in a 'write' call. This might be an issue of coincidence, because when I get a backtrace of the "running" highlight, then it is also stuck in a write call, initiated by an 'fflush' call, as can be seen below. These two writes seem to block each other. Doing an interruption in some way, like getting a backtrace of the stuck evolution with a gdb, recovers it again and evolution starts to use high CPU, finally (after couple seconds) populating the message preview. Interestingly, I can reproduce this even with highlight 3.16-1, while I wasn't able to reproduce it right after importing the message. Probably a good luck or something like that. This all was supposed to be fixed by an upstream bug report [1], which I'm reopening. [1] https://bugzilla.gnome.org/show_bug.cgi?id=724909 Backtrace from highlight: Thread 1 (process 20133): #0 0x00000033e16e67e0 in __write_nocancel () from /lib64/libc.so.6 #1 0x00000033e1676c83 in _IO_new_file_write () from /lib64/libc.so.6 #2 0x00000033e16780ec in __GI__IO_do_write () from /lib64/libc.so.6 #3 0x00000033e1676510 in __GI__IO_file_sync () from /lib64/libc.so.6 #4 0x00000033e166c03b in fflush () from /lib64/libc.so.6 #5 0x00000033e869607e in std::ostream::flush() () from /lib64/libstdc++.so.6 #6 0x00000033e867f12c in std::istream::sentry::sentry(std::istream&, bool) () from /lib64/libstdc++.so.6 #7 0x00000033e8676d3d in std::basic_istream<char, std::char_traits<char> >& std::getline<char, std::char_traits<char>, std::allocator<char> >(std::basic_istream<char, std::char_traits<char> >&, std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, char) () from /lib64/libstdc++.so.6 #8 0x00000000004383bb in highlight::CodeGenerator::readNewLine(std::string&) () #9 0x000000000043ca51 in highlight::CodeGenerator::getInputChar() () #10 0x000000000043cbf5 in highlight::CodeGenerator::getCurrentState(highlight::State) () #11 0x000000000043d3a8 in highlight::CodeGenerator::processSymbolState() () #12 0x000000000043e372 in highlight::CodeGenerator::processRootState() () #13 0x000000000048ad57 in highlight::HtmlGenerator::printBody() () #14 0x000000000043a7b5 in highlight::CodeGenerator::generateFile(std::string const&, std::string const&) () #15 0x0000000000412e0e in HLCmdLineApp::run(int, char const**) () #16 0x0000000000406a89 in main ()