Description of problem: I do not know the certain conditions of how this actually happens, but occasionally evolution starts some task (the wheel starts spinning in the status bar at the bottom of the screen), and evolution starts to eat cycles like crazy: showing something around 105-110% in top on my 2 core machine. It continues to work, but using evolution becomes very choppy. The task spinning is usually 'Checking for new mail'. Such task does not seem to finish itself (or perhaps I haven't waited long enough). When I attempt to cancel that task using the red button, the title switchces to '... (cancelling)', but nothing else actually happens. If I try to close Evo under these conditions, all goes grey, but it does not terminate in any sane time. I always had to use '--force-shutdown', which responded: 'No response from Evolution -- killing the process' Version-Release number of selected component (if applicable): evolution-3.2.1-2.fc16.x86_64 How reproducible: happens several times a day, but I don't see anything specific launching it. Steps to Reproduce: 1. I don't know Additional info: Evolution started to behave like this in some recent F16 update, I haven't seen this behavior before. I suspect this one: * Mon Oct 17 2011 Milan Crha <mcrha> - 3.2.1-1 - Update to 3.2.1
Thanks for a bug report. Could you install debug info packages for evolution-data-server, evolution, gtkhtml3 and any other evolution* packages you use, of the same version of those packages, and provide a backtrace of such stuck state, please? You can do that by running command like this: $ gdb --batch --ex "t a a bt" -pid=PID &>bt.txt where PID is a process ID of the running evolution. The backtrace may show us what is evolution doing. Thanks in advance.
Created attachment 531135 [details] Backtrace Backtrace obtained during evo spinning 120%, the task in status bar was "Saving user interface state"
Thanks for the update. The backtrace shows that you've enabled quite many imapx accounts, same as many Search folders, which are being updated currently, which is the task which takes so much of CPU. It thinks that you've removed some of your messages, thus it's removing them from those search folders. I do not see from it whether it's a Search folder as such or a junk/trash virtual folder associated with each account. There is nothing much I can do at the moment, the 3.3.1 contains changes in the CamelFolderSummary, which may speed up certain operations, but the real fix would be some change in CamelVeeFolder, probably kind of rewrite. I've no exact idea, though.
Well, I have five email accounts, and one of them is really heavily used (guess which one :). I have no special search folders except for the junk/trash ones. Does not seem much like an overload. Is there anything I can change in my settings to not trigger this behavior?
Unfortunately not, the folders may not work otherwise. I'm wondering whether a crash didn't break any of your summary files, which can then lead to particularly anything, though the backtrace doesn't show any sqlite activity. Depending on your accounts, their folders.db files can be located either in ~/.local/share/evolution/mail or ~/.cache/evolution/mail (though the later can be part of 3.3.x development only). Moving these folders.db files away, then running evolution and let it recreate all this information (it'll be significantly slower the first time) will at least cleanup those db files, though do not delete them, rather move away/rename them, thus you'll be able to return to them if something will go wrong.
Wow, it actually helped. Thank for the advice!
Ah, good. I've no idea whether the code can check for such folders.db failures, but as you've it fixed manually, I'm closing this report.