GNOME Bugzilla – Bug 682295
git head deadlocks
Last modified: 2013-09-13 01:07:02 UTC
Created attachment 221892 [details] stacktrace of deadlocked evo git head deadlocks within minutes of starting up. consistently showing in the status bar with every lock up is 'Saving user interface state' other status indicators vary ala 'Unknown background process', 'Retrieving message' etc
I see again lot of handle_http_request calls in the backtrace. Are the deadlocks related to messages with remote images?
(In reply to comment #1) > I see again lot of handle_http_request calls in the backtrace. Are the > deadlocks related to messages with remote images? A very quick test indicates that it appears that may be the case. I can move from plain text email to plain text email with no problem, but selecting an html email with links deadlocks evo. I have to leave for the day, but should be back online with evo aroung midmorning tomorrow.
OK -- i've narrowed it down some I think. If I turn off loading of images from the internet, then evo doesn't deadlock. I can look at as many html emails as i want ( quick test == 12 to 15 ) without issue. If I turn load images from internet back on, then select an html email, evo deadlocks.
Created attachment 222161 [details] [review] Patch Reid, could you please try to reproduce the issue with this patch? The problem seems to be in not using different GMainContexts for each request, which eventually leads to deadlocks.
(In reply to comment #4) > Created an attachment (id=222161) [details] [review] > Patch > > Reid, could you please try to reproduce the issue with this patch? > > The problem seems to be in not using different GMainContexts for each request, > which eventually leads to deadlocks. applied patch to current git head and rebuilding now. it will be tomorrow morning before i'm in the office to test though
(In reply to comment #5) > (In reply to comment #4) > > Created an attachment (id=222161) [details] [review] [details] [review] > > Patch > > > > Reid, could you please try to reproduce the issue with this patch? > > > > The problem seems to be in not using different GMainContexts for each request, > > which eventually leads to deadlocks. > > applied patch to current git head and rebuilding now. it will be tomorrow > morning before i'm in the office to test though still deadlocks when attempting to view html with 'Always load images from internet' active. status bar shows 'Retrieving message' and 'Saving user interface state' tasks. I'll post an attached gdb backtrace next.
Created attachment 222219 [details] backtrace associated with commnt # 6 backtrace associated with commnt # 6
Reid, are you sure this is the right backtrace or that you have applied the patch correctly? The line numbers in the backtrace match git master _without_ the patch.
h(In reply to comment #8) > Reid, are you sure this is the right backtrace or that you have applied the > patch correctly? The line numbers in the backtrace match git master _without_ > the patch. hmm -- ok -- will rebuild and re-test. I thought I had rebuilt after applying last night but it's very possible that I failed to do that, it was very late. sorry.
Created attachment 222232 [details] backtace of deadlocked evo after applying patch and rebuilding in reference to comment 9
Reid, could you please try the patch again with latest libsoup >= 2.39.5?
(In reply to comment #11) > Reid, could you please try the patch again with latest libsoup >= 2.39.5? sorry for the delay. had to configure my system to build glib & glib-networking from git to get a high enough version for libsoup to compile. Initial testing jumping from multiple plain and html emails back and forth shows no deadlock -- response time seems to be quite good. Will advise if anything pops up. drwxr-xr-x 8 rthompso staff 4096 Aug 29 11:43 libsoup-2.39.5 [11:48:39][0s] rthompso@raker2> ~/evo-git-head $ cd glib [11:48:47][0s] rthompso@raker2> ~/evo-git-head/glib $ git branch * 2-33-10 glib-2-32 master [11:48:51][0s] rthompso@raker2> ~/evo-git-head/glib $ cd ../glib-networking/ [11:48:57][0s] rthompso@raker2> ~/evo-git-head/glib-networking $ git branch * 2-33-10 glib-2-30 master [11:48:58][0s] rthompso@raker2> ~/evo-git-head/glib-networking
The patch doesn't work fully for me, with libsoup 2.38.1-1.fc17.x86_64, but it's known to not work (see bug #683935). With the patch I see on console this one message as new: libsoup-CRITICAL **: soup_session_pause_message: assertion `item != NULL' failed when it tries to download new images from internet, but again, this is the old libsoup, with using unstable API, thus it's OK. Dan, feel free to commit. Reid, maybe you can try to close evolution and get rid of ~/.cache/evolution/http/ where all the remote images are saved, thus the next time you'll select an HTML message with remote images they all will be downloaded again, thus the change Dan did will take into effect.
Created attachment 224338 [details] [review] Updated patch As discussed on IRC, we can't use the synchronous libsoup API in EHttpRequest, because it's not supported by libsoup<2.39 (and we depend on 2.38 at this moment). This patch replaces use of libsoup 2.39 features by another approach (synchronous as well) used for example in CalDAV. It also contains changes from the patch above, e.g. each SoupSession having it's own GMainContext, which fixes the deadlock issue. I didn't test it against libsoup 2.38, but the code is copied from the CalDAV code, so it should work as expected (works perfectly with 2.39).
Comment on attachment 224338 [details] [review] Updated patch Committed to git master for Evolution 3.5.92+ as 11bdb5d http://git.gnome.org/browse/evolution/commit/?id=11bdb5d83a6e1174310ad4cabd7b6db5ef54263d
Works for me with 3.5.92, images are downloaded, and no warnings on console anymore. Thanks. For the patch, maybe jus tone thing, if the sender malforms the image URL, then the soup_message_new() fails and returns NULL. The current version just crashes in such case (you didn't take exact copy from CalDAV) :) It might be good to have this fixed after the freeze next week (for 3.6.1).