Created attachment 599045 [details] htop screenshot Description of problem: After all the messages was received (I know the total number of messages) Evolution a long time given high CPU utilization. I did not wait and went to bed. At morning CPU usage returned to normal. What was it? I attach also backtrace.
Created attachment 599046 [details] backtrace evolution
"pool" process (23141) at htop screenshot owns to evolution. When I kill "pool" process evolution is terminated, but when I launch evolution again, I see again "pool" process and CPU utilization not stop.
Thanks for a bug report. The current backtrace snapshot shows each thread in idle, basically polling. This should not take any CPU, because they are basically waiting for some signal. Thread 3 has running EWS' folder updating, it's synchronizing items which changed on the server. It can take its time depending on the folder size. I do not see what folder this is about from the backtrace, though.
I think this is related to upstream bug [1]. I'm moving this there. I'm also building a test package [2] which should address this issue. [1] https://bugzilla.gnome.org/show_bug.cgi?id=656709 [2] http://koji.fedoraproject.org/koji/taskinfo?taskID=4261460
I'm sorry, there was a typo in the patch in the previous build ([2]). This build contains fixed patch from the upstream bug: http://koji.fedoraproject.org/koji/taskinfo?taskID=4261734
Great job!!! Today I work with evolution-ews-3.4.3-1.8 and not one crash was not. But when I tried to close the evolution for update to evolution-ews-3.4.3-1.9, evolution interface was stuck :( I attach backtrace this case here:
Created attachment 599107 [details] backtrace for evolution (stuck occurs when I close evolution) (evolution-ews-3.4.3-1.8)
Created attachment 599230 [details] htop screenshot
Created attachment 599231 [details] backtrace evolution
Hmm, the first backtrace shows each thread idle, no operation is shown as pending or anything. the second thread shows many threads waiting for a message download, and the main thread doing window updates. Maybe that's it, the window is repainted periodically for some reason and it does it that often that it uses high CPU. That's just a guess, I cannot tell for sure from the backtraces.