GNOME Bugzilla – Bug 578577
deadlock in contact image lookup leading to evo hang formatting message
Last modified: 2012-05-09 09:26:17 UTC
+++ This bug was initially created as a clone of Bug #361145 +++ There appears to be a deadlock in EDS when looking up contact images for message display in Evolution. This causes Evo to become stuck when displaying a message in the preview plane, with the status bar displaying "Formatting message..." but the message never actually appearing. Disabling contact lookup display seems to fix getting stuck at formatting message for me. Splitting this off of bug #361145 as the request of Milan Crha.
Blocking #361145 since it is one cause of the "Formatting message" hang.
Created attachment 132445 [details] back trace from eds, 2.26.0-0ubuntu2 (near svn head) (from bug #361145 comment #65) > OK, I do not understand why it does so, but this is a deadlock in eds. > From your traces, thread 2 holds the lock which thread 1 is waiting on, but > thread 2 wants to notify on thread 1, which is "busy".
Created attachment 132446 [details] back trace from evo, 2.26.0-0ubuntu2 (near svn head)
Created attachment 132447 [details] stdout from eds at the time of the deadlock
From the eds backtrace, it thinks the "client" of the EBook crashed (or something very similar), thus it calls that idle_remove_client, which is invoked in e-book-backend.c:listener_died_cb Maybe it's called as part of the notification about online status, which is the thing doing in the Thread 2. Could you run evolution-data-server under gdb with a breakpoint into the above listener_died_cb and paste here backtrace of its call? (I guess you know how to do that, if not, just ask.) Thanks. One silly question, there is nothing special about your online/offline state, or the medium where is your personal address book stored, is it? It's strange to me to be notified about online state on the local storage.
Created attachment 132457 [details] back trace from a call to e-book-backend.c:listener_died_cb This is the bt and surrounding eds/gdb output from a call to e-book-backend.c:listener_died_cb triggered by a message load, although after continuing it didn't actually get stuck on in formatting. I'll keep looking for one of those.
eh, I forgot the orbit thing, it sends the 'die' signal async too. Hard to find why it died. Hmm, maybe it was just closed. I just tried to be sure and this function is not called for me when moving between messages in a folder, only when I close evolution.
Hmm, I don't think it is just being closed because typically when the break point is hit it gets hit many times, which seems pretty odd for normal behaviour.
Looking around the breakpoint, is it always the same or different? We should be able to find out the reason for calling this, but as this is called async from ORBit2, it'll be harder. Could you install also debug info packages for ORBit2 (might be libORBit2 or something like that), and then put breakpoint to linc-connection.c:add_idle_broken_for_cnx_T that might show us what connection type changed and hopefully why, as this, I hope, is not called async.
I'm marking this as a duplicate of bug #361145 (back to the roots), because I'm not aware of any other reason of the stuck 'Formatting message' activity in current stable evolution (3.4.1). *** This bug has been marked as a duplicate of bug 361145 ***