GNOME Bugzilla – Bug 712578
MH folder refresh can cause summary rebuild
Last modified: 2014-01-09 18:29:22 UTC
Moving this from a downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1023758 Description of problem: Evolution consistently runs to 100% CPU when dealing with claws-mail mh folders. Version-Release number of selected component (if applicable): evolution-3.8.5-2.fc19.x86_64 How reproducible: Very Steps to Reproduce: 1. have mh folder from claws-mail (~ 512 MB in size) 2. setup mh folder using evolution add new account 3. startup evolution move a message between another account and mh folder Actual results: Evolution hangs runs CPU up. Expected results: Mail message moved to mh folder ------------------------------------------------------------------------------ Backtrace snapshot of one update:
+ Trace 232790
Thread 4 (Thread 0x7f2b5f7fe700 (LWP 30705))
I cannot reproduce this with git master, eds at commit 712829, which might be the same (or very close to) as 3.10.x in this part.
(In reply to comment #1) > I cannot reproduce this with git master, eds at commit 712829, which might be > the same (or very close to) as 3.10.x in this part. I take this back, I managed to reproduce this when I add a new message to the mh folder. This message is always re-added to the summary after each "Refresh" call.
Created attachment 262943 [details] [review] eds patch for evolution-data-server; This should make it work as expected, after the first refresh. There seems to be an issue with X-Evolution header treatment, as it also holds message's UID. When I copy a message with one UID stored inside it, then the actual file UID in MH folder doesn't match the one in the message itself, which causes re-additions due to a try to also index the message. The patch makes sure the UID being used is the correct one, not the one from X-Evolution message header.
Created commit 922f0ef in eds master (3.11.3+) Created commit e41baf5 in eds gnome-3-10 (3.10.3+)
Update following on from bug filed: Redhat #1023758 https://bugzilla.redhat.com/show_bug.cgi?id=1023758 Installed Evolution products: evolution-3.8.5-2.fc19.x86_64 evolution-data-server-doc-3.8.5-6.fc19.noarch evolution-debuginfo-3.8.5-2.fc19.x86_64 evolution-data-server-debuginfo-3.8.5-6.1.fc19.x86_64 evolution-bogofilter-3.8.5-2.fc19.x86_64 evolution-rss-0.3.93-3.fc19.x86_64 evolution-data-server-devel-3.8.5-6.1.fc19.x86_64 evolution-data-server-3.8.5-6.1.fc19.x86_64 I've tested the new data-server rpm and initially all looked well. I was not seeing reindexing of the mh folder by opening a second instance of evolution from the Gnome calendar link. However after rebooting and first load I had to wait for a full reindex and reset the message status to read again. Frustratingly the email with the link back to the bug ID and gdb trace command was trapped by the folder rebuild so I was unable to track it. However since the final rebuild I have not been able to trigger a reindex via the calendar or refresh folder routes. I will try another reboot to see if all is ok and confirm fixed if that is the case.
So far no additional reindexing of mh triggered. CPU utilisation appears to be normal no more 100% utilisation. I think this looks closed?
Hmmm as soon as I write it is fixed it comes back to bite me. I've just moved an email from an imap folder into the mh and now have: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4862 USERNAME 20 0 4222284 110704 57560 S 103.4 1.4 49:49.45 evolution in top. The mh is frozen with Evolution. I have a backtrace running on the pid and evolution just says "moving messages into folder inbox". I am going trigger an evolution --force-shutdown to see if I can regain control of evolution.
Created attachment 263421 [details] BackTrace from PID at 100% Evolution CPU usage Backtrace taken using command: gdb --batch --ex "t a a bt" -pid="4862" &>bt5.txt When CPU was at 100% by Evolution. Triggered on moving email from imap to mh folder. Evolution --force-shutdown command used to terminate evolution.
Started evolution and found that mh inbox empty checked CPU usage: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 6401 USERNAME 20 0 4136268 96888 52772 S 100.0 1.2 2:06.82 evolution Currently running BT on PID as previous. Send and receive sits indefinitely on "Updating..." for mh account. I think the new version of evolution-data-server-3.8.5-6.1.fc19.x86_64 may have reintroduced the bug? I will kill evolution again and clear all the files from the mh that are evolution based after exploring the folders.db. Interestingly the folders.db shows it was last written to at 16:16 and is 5.0MB in size. Some two hours ago. By removing the folders.db - evolution starts and runs at 17 to 25% CPU usage effectively it would appear to be reindexing the mh. I have a BT for it and will attach below. On completing the reindexing evolution drops back to normal usage and the folders.db is now 3.1MB. Marking all the messages as read changes this to 3.3MB
Created attachment 263424 [details] BackTrace from PID after folders.db removed and evolution rebuilds Previous instance of Evolution killed with --force-shutdown Folders.db removed from mh related directory in evolution structure (.local/share...). Evolution started pid monitored. mh reindexed and messages shown as new (some not all?) Changed to all marked as read. Shutdown evolution via menu as normal.
(In reply to comment #9) > Send and receive sits indefinitely on "Updating..." for mh account. I think the > new version of evolution-data-server-3.8.5-6.1.fc19.x86_64 may have > reintroduced the bug? Hrm, I see I made two different 3.8.5-6.1, one for you, at [1], but then also [2], for bug #704513 comment #31. I do not have sources for any of these, unfortunately. I'm sorry for the version confusion, it makes this a mess. [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=6232099 , see [3] [2] http://koji.fedoraproject.org/koji/taskinfo?taskID=6234189 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1023758#c28