GNOME Bugzilla – Bug 667281
Deadlock on evolution start
Last modified: 2013-09-13 01:06:23 UTC
I have configured real junk and trash folder on one of my two IMAP accounts. I have configured also exchange and mapi account. I have search folder which is using two folders from the IMAP account and one from local store (the same IMAP account as the real junk/trash folder is configured), though it's probably not related, because evolution doesn't start, it doesn't get that far to try to do anything useful with the search folder. See the below backtrace. I feel like this is a regression on "semi-recent" changes in evo/eds, because 3.2.3 starts as expected with this setup.
+ Trace 229390
Thread 5 (Thread 0x7f0ed7328700 (LWP 9787))
Thread 1 (Thread 0x7f0edf02d9c0 (LWP 9786))
Tested with 3.2 and it does not open junk & trash folders like 3.3 does on start.
Downstream bug report about the same: https://bugzilla.redhat.com/show_bug.cgi?id=772585
I'm wondering which component is proper for this issue, because changes in both evo and eds are causing it. I'm moving it to evo, because that's the place where I'll do the change, but the problem is with eds itself, and how it was "recently" changed.
Created attachment 204943 [details] [review] evo patch for evolution; I do not like how this is done. There are couple problems here. The first one is in evolution, the code to open Junk and Trash folders had been added in commit [1]. I do not know what it has to do with drag&drop of accounts, but I pile various things in one commit sometimes too, thus OK. The only issue is that this calls synchronous camel function from the main thread, which is basically no-no. The issue which this change uncovered dates back to commit [2], where was added imap_store_update_store_flags as a callback on notify::settings. I thought this is not called at all, but no, it is called, only the settings are not loaded yet. The best option would be to add signal handlers into the settings on notifications for the values it operates with, but I realized I cannot disconnect from them appropriately (before camel_service_set_settings changes it), thus I didn't go this way. Should I have my own copy of the settings of my parent object's property to be able to properly connect/disconnect for signal handlers on them? It can be done, but sounds rather ugly - may result in a copying in each CamelStore. The result of the above findings is attached. I consider it a temporary solution, which, I believe, will be gone as soon as account-management branch will land master, replaced with appropriate change, which will also involve removal of the temporary camel_settings_load_from_url() function. Thus: Just for now. [1] http://git.gnome.org/browse/evolution/commit?id=7c0c40f833 [2] http://git.gnome.org/browse/evolution-data-server/commit/?id=ffa02a8e2
Created commit 11c24da in evo master (3.3.4+)