Bug 841443

Summary: What evolution to do? (high CPU utilization after receiving all messages)
Product: [Fedora] Fedora Reporter: Mikhail <mikhail.v.gavrilov>
Component: evolution-ewsAssignee: Matthew Barnes <mbarnes>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: lucilanga, mbarnes, mcrha
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-07-19 09:24:12 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
htop screenshot
none
backtrace evolution
none
backtrace for evolution (stuck occurs when I close evolution) (evolution-ews-3.4.3-1.8)
none
htop screenshot
none
backtrace evolution none

Description Mikhail 2012-07-19 02:46:01 UTC
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.

Comment 1 Mikhail 2012-07-19 02:47:22 UTC
Created attachment 599046 [details]
backtrace evolution

Comment 2 Mikhail 2012-07-19 02:57:48 UTC
"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.

Comment 3 Milan Crha 2012-07-19 08:22:14 UTC
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.

Comment 4 Milan Crha 2012-07-19 09:24:12 UTC
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

Comment 5 Milan Crha 2012-07-19 09:47:08 UTC
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

Comment 6 Mikhail 2012-07-19 10:14:05 UTC
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:

Comment 7 Mikhail 2012-07-19 10:15:20 UTC
Created attachment 599107 [details]
backtrace for evolution (stuck occurs when I close evolution) (evolution-ews-3.4.3-1.8)

Comment 8 Mikhail 2012-07-19 19:30:57 UTC
Created attachment 599230 [details]
htop screenshot

Comment 9 Mikhail 2012-07-19 19:31:47 UTC
Created attachment 599231 [details]
backtrace evolution

Comment 10 Milan Crha 2012-07-24 07:25:52 UTC
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.