| Summary: | evolution sometimes goes very cpu-intensive and cannot be ended normally | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Petr Muller <pmuller> | ||||
| Component: | evolution | Assignee: | Matthew Barnes <mbarnes> | ||||
| Status: | CLOSED WORKSFORME | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 16 | CC: | lucilanga, mbarnes, mcrha, ohudlick | ||||
| 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: | 2011-11-08 07:05:32 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
|
Description
Petr Muller
2011-10-31 10:51:43 UTC
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. |