GNOME Bugzilla – Bug 692278
LDAP backend mutex deadlock on finalize
Last modified: 2013-01-22 19:45:49 UTC
Created attachment 234093 [details] Evolution backtrace 3.6.2 Using corporate LDAP server as an address book and trying to reply to a mail within corporate IMAP(x) account. Pressing the Reply button makes whole Evolution frozen for significant amount of time while waiting for a Composer window to open.
Created attachment 234094 [details] e-d-s backtrace
Known issue. See the Evolution backtrace, Thread 1. I'll be deprecating e_book_client_new() soon for blocking like this.
It's not it. The reason is that the factory is stuck due to LDAP backend waiting for a lock. This DBus call takes only milliseconds, and is basically unavoidable, especially if you want to use the EBookClient instance immediately after the e_book_client_new() call. A better general fix is to avoid backends doing anything on the factory's main thread, thus add some EBackend functions for timeout/idle/thread invoking, which will run anything scheduled in a dedicated thread, rather than the main thread, which is used by DBus. Nonetheless, the issue is with LDAP itself here, I'm checking what happened.
Both issues need fixed. The UI blocking is the more egregious.
Created attachment 234132 [details] [review] eds patch for evolution-data-server; (gnome-3-6) This should make it, the LDAP deadlocked on mutexes. One thread holds the op_hash_mutex, while another (the main thread) holds eds_ldap_handler_lock. The main thread asks for the op_hash_mutex, and the other thread asks for the eds_ldap_handler_lock, thus no luck for both. This fix just locks the eds_ldap_handler_lock before any use of op_hash_mutex, to avoid the deadlock.
Relevant part of the eds backtrace (for easier searching):
+ Trace 231415
Thread 1 (Thread 0x7fedd04a9740 (LWP 28087))
Created commit 98d297d in eds master (3.7.5+) Created commit a84d026 in eds gnome-3-6 (3.6.4+)