GNOME Bugzilla – Bug 651823
[regression] Deadlock with folder's summary and transaction lock
Last modified: 2013-09-13 01:06:46 UTC
I was editing my mail (using today's git master). I'd been deleting mail's as well as labeling some as spam (which goes through spamassassin). The UI has frozen. I get the following backtrace: (gdb) thread apply all bt full
+ Trace 227367
Thread 12 (Thread 0xa55ffb70 (LWP 23222))
Thread 10 (Thread 0xab7ffb70 (LWP 23233))
Thread 9 (Thread 0xaafffb70 (LWP 23234))
Thread 8 (Thread 0xacbffb70 (LWP 23235))
Thread 7 (Thread 0xa97ffb70 (LWP 23236))
Thread 6 (Thread 0xa8dffb70 (LWP 23237))
Thread 5 (Thread 0xa85ffb70 (LWP 23238))
Thread 4 (Thread 0xa7dffb70 (LWP 23239))
Thread 3 (Thread 0xa75ffb70 (LWP 23240))
Thread 2 (Thread 0xa6dffb70 (LWP 23241))
Thread 1 (Thread 0xb594a830 (LWP 22730))
(evolution:22730): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to underallocate EMailDisplay's child GtkScrolledWindow 0xa7de4d0. Allocation is 822x5982, but minimum required size is 841x6010. (evolution:22730): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to underallocate EMailShellContent's child EAlertBar 0x9db6dc8. Allocation is 857x0, but minimum required size is 0x45. (evolution:22730): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to underallocate EMailDisplay's child GtkScrolledWindow 0xa7de4d0. Allocation is 822x5982, but minimum required size is 841x6010. on the console.
Thread 1 - is waiting for a summary lock Thread 2, 3, 4, 5 - are waiting for local folder's search lock, the DB writer lock is not held yet, the transaction didn't begin Thread 6, 7, 9, 10, 12 - are waiting for local folder's search lock, the DB writer lock is not held by this, the transaction already finished Thread 8 - is waiting for a folder's summary lock, while it hold the DB writer lock, because the transaction is undergoing Thread 11 - is waiting for a DB writer lock, while it holds the summary lock; it holds also local folder's search lock Thread 13 - is downloading an image Thread 14, 15 - in idle ---------------------------------------------------------------------------- Thus it seems threads 8 and 11 are the cause. The folder summary lock should be always held before the DB writer lock (before the DB transaction is run), or after it.
This is most likely caused by changes around bug #640054
Created attachment 189316 [details] [review] proposed eds patch for evolution-data-server; I do not see it myself, thus I would like to ask you to give a try to this patch. It makes sure that the folder's summary lock is always held before the transaction writer lock, though due to technical reasons I was unable to cover really all places, for example those which are accessing DB from CamelFolder itself and when providers are calling DB functions. Anyway, this may fix your issue.
I applied the patch, and so far the problem hasn't reappeared. On the other hand, I don't think that this happened very often.
(In reply to comment #4) > I applied the patch, and so far the problem hasn't reappeared. On the other > hand, I don't think that this happened very often. OK, thanks. There is a 3.1.2 release the next week, thus if you'll not see any regression with the patch then I'll commit it on Friday.
*** This bug has been marked as a duplicate of bug 640054 ***
Comment on attachment 189316 [details] [review] proposed eds patch An alternative patch to fix this issue has been posted at https://bugzilla.gnome.org/show_bug.cgi?id=640054#c28
I backed out Milan's patch and rebuilt from a fresh git/master. I've just encountered another hang, switching from mail to calendar. (I'd been reading my e-mail for a while). Here's another backtrace: (gdb) thread apply all bt full
+ Trace 227435
Thread 3 (Thread 0xb4effb70 (LWP 21839))
Hmm, I do not see a real hang in the backtrace, not the one usually showed when an application is stuck. Strange.
*** Bug 652994 has been marked as a duplicate of this bug. ***