Created attachment 599233 [details] gdb backtrace Description of problem: Can't change to a different imap folder sometimes, get "saving user interface state". Version-Release number of selected component (if applicable): evolution-3.2.3-3.fc16 How reproducible: tricky :-( Steps to Reproduce: So, e.g. in a "fecora-vcs" folder which is filled by zimbra server side filtering commit emails. Try to move to a new folder, perhaps while email is appearing in the old folder. New folder gets highlighted, but "saving user interface state" appears and we don't actually switch to the new folder, the contents of the old folder remain, and remain getting updated, so the app hasn't actually hung, and deleting the mails that appear updates the folder count of unread mails, but inability to move to another folder persists. Often it "unsticks" eventually. Additional info: All (28) imap folders are filled by server side filtering for this account. There is another account as well with 8 imap folders. Possibly the same problem as bug 750204. Feel free to not agonize over this and close it out rapidly, but seeing as I have a backtrace with symbols (34 thread?) during the sluggishness I'd like to have someplace to put it. And maybe I'll upgrade to F-17 in the meantime and see if it persists.
Created attachment 599236 [details] another trace here's another trace, but with an instance of evolution executed after gconftool-2 --set --type=bool /apps/evolution/mail/display/enable_vfolders false
Thanks for a bug report. Each IAMPx account spawn its own parser thread, and if you have enabled IDLE (server notifications) for the account, then also an idle thread. It's approximately 2/3 of the first backtrace threads. The rest is updating your virtual trash folder for one account, interestingly in more than one thread. Thread 9 is removing messages from the folder, probably because you moved away from it and the folder was freed. I guess you may also see higher CPU usage in this time? Once it's done the other threads are getting into action, and, as you wrote, it eventually "unsticks". The second backtrace is basically about the same, it's removing message infos from your trash folder (I cannot tell for which account, but most likely for the same you change folders in). Whether update for evolution 3.4.3 in Fedora 17 will help I cannot tell for sure, there was added a batch removal of message infos from folder summary for IMAPx accounts, but it's used only there, not in vFolders - as far as I can tell. I made significant changes in vFolders for 3.5.3, though it has other issues (memory requirements), which is subject to change soon. Just wondering, how large are your folders, especially when you invoke View->Show hidden messages? I'm interested in total counts and in deleted counts. You can get the counts as stored in folders.db file with this command: $ sqlite3 ~/.cache/evolution/mail/<imapx-account-id>folders.db \ "SELECT folder_name,saved_count,deleted_count,junk_count,jnd_count \ FROM folders" Where the imapx-account-id is some strange string. You may check subfolders of the folder to get the right account. I'm not sure in 3.2.x, maybe the accounts are not stored in ~/.cache, but in ~/.local/share/evolution/mail/<user@host>/ or even in ~/.evoltuion/mail/<user@host>/ , but the folder always contain the folders.db file. By the way, is the folders.db file large for you?
"is the folders.db file large for you?" its currently 55M in size, how would I know if that's a suboptimal size ? Maybe what I've got going here is massive accumulations of unexpunged trash over time and I need an auto-expunge trash over X days old thing :-)
55MB doesn't sound that bad, mine has almost 290MB. Vacuuming it helps in speed if there are too many free chunks, but I think it's not your case. You have only 622 deleted emails and gathered 164 spam messages in virtual folders. If I count properly, then it's about 50771 messages in all folders, which is nothing significant. I have over 318000 messages and it works reliably here. (Fedora 17, IMAP provider (not IMAP+).
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.