GNOME Bugzilla – Bug 592310
Deadlock in maildir provider after doing expunge
Last modified: 2013-09-13 01:04:58 UTC
Evolution 2.27.90 I have maildir account which i use as back up account for my corporate mails. Inbox in maildir has approx 33k mails. I deleted a few of them (approx 40 mails) and did expunge. After some time evolution cpu had reached at 100% and remained there till i did force shutdown. Status bar was showing 'storing folder..' and 'checking folder consistency'. gdb traces
+ Trace 217009
Thread 4 (Thread 0x7f7eddef8950 (LWP 10294))
Thread 3 (Thread 0x7f7edd6f7950 (LWP 12915))
Thread 2 (Thread 0x7f7eef7fe950 (LWP 13245))
see bug 592312 also
(In reply to comment #1) > see bug 592312 also I believe it's the same thing.
Created attachment 141239 [details] [review] proposed eds patch for evolution-data-server; I changed couple things: a) with maildir and mh folders I removed the summary_check call in get_message and append_message functions, as it scans all the folders, which is slowing things (for example when copying new messages to the folder) b) The main cause of this bug was message_info_free, it was removing message info from the loaded_infos by uid, but for maildir is tested whether newly created info has a UID which is in loaded infos, and the previous one is freed, in favour of the loaded info. (beh, description doesn't make much sense, and is also longer than the fix itself).
*** Bug 592312 has been marked as a duplicate of this bug. ***
Patch improves things drastically. After applying the patch cpu didn't go up and i was able to see mails in folder. Thanks Milan.
Created commit 03f4c1c in eds master (2.29.1+) Created commit 57912dd in eds gnome-2-28 (2.27.91+) Thanks for testing.
Milan, Not sure, if your change to remove the _check is right. Evo's local providers are written to take care of off-the-record changes. For Example, there is a change in mail dir folder not through Evo, check would reload/create the summary. It was the case with MBOX. This thing, can potentially corrupt your summary at some point. Akhil, can you see, if there is a way u can change mail dir without evo and try to copy to that maildir, with out loading that maildir? Just test this scenario.
(In reply to comment #7) > Milan, Not sure, if your change to remove the _check is right. Basically, having the check method in the append_message function means doing the folder scan on each append. That's a very expensive operation, especially when you are copying new messages from one folder to the other (I tried 4K messages from an mbox store to the maildir store, the performance impact was significant).
Things are not going right again :( Here it is what i did 1. Open maildir folder (which i am accessing through evolution) in kmail, evolution is not running at the moment 2. Verify the mail count , both application show the same count. Didn't open both the applications at the same time 3. Now delete 2 mails using kmail, close it 4. Open evolution, it shows 'consistency check ..'. If i click on other folder where i didn't make any change, things go smooth. I waited for half an hr but evolution didn't show me any mail in folder where i deleted 2 mails. I see these warnings on evolution terminal (evolution:24787): camel-local-provider-CRITICAL **: maildir_cmp_uids: assertion `a != NULL' failed (evolution:24787): camel-local-provider-CRITICAL **: maildir_cmp_uids: assertion `a != NULL' failed (evolution:24787): camel-local-provider-CRITICAL **: maildir_cmp_uids: assertion `a != NULL' failed (evolution:24787): camel-local-provider-CRITICAL **: maildir_cmp_uids: assertion `b != NULL' failed (evolution:24787): camel-local-provider-CRITICAL **: maildir_cmp_uids: assertion `b != NULL' failed
Gdb traces of evolution when it was showing 'folder consistency..'
+ Trace 217122
One more time gdb traces
+ Trace 217123
Akhil, I cannot reproduce it with the actual master, eds 6bab6bf, evo 47a95c9 Can you reproduce it when you remove mails with a file manger? Maybe it also depends on the file position too, as the first, middle or last files? Are files removed by kmail removed permanently or just some flag is added to the file (flags are characters after the last ':' in the file name). I tried all these (except of kmail), and it all works fine for me.
Milan, I think its better not to have this patch in stable branch unless it is confirmed that its not going to break existing thing. what do u think ?
It's in already, do you mean to revert it? I'm keeping it up to you, just note that the part from camel/camel-folder-summary.c is good to have there, as it's the right fix. The rest of the patch, all those removals, are for a performance. I believe it's ok to have it in stable.
I have added an environment variable SKIP_LSUMMARY_CHECK and if its set the summary check will not be performed. So people who are sure that other clients wont update the cache can set this environment variable. Have committed the patch to stable branch only.
*** Bug 601416 has been marked as a duplicate of this bug. ***