Fixes possible deadlock between history and bookmarks. The deadlock

would occur if you attempted to exit the browser, bookmarks hadn't
finished loading yet and HistoryBackend was waiting for bookmarks to
finish loading. In such a scenario bookmarks will never finish loading
because the UI thread is blocked waiting for history to finish
shutdown, but history can't finish because it's waiting for bookmarks.

I'm fixing it by signaling that bookmarks have finished loading, even
though that isn't entirely accurate in this case. It's possible that
could lead to nuking some favicons for bookmarks, but this scenario is
so rare that (IMO) it's not worth trying to handle specially.

BUG=96100
TEST=none
R=brettw@chromium.org

Review URL: http://codereview.chromium.org/7891018

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@101076 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 9 insertions, 0 deletions

diff --git a/chrome/browser/profiles/profile_impl.cc b/chrome/browser/profiles/profile_impl.cc
index 83e45df..e698177 100644
--- a/chrome/browser/profiles/profile_impl.cc
+++ b/chrome/browser/profiles/profile_impl.cc
@@ -804,6 +804,15 @@ ProfileImpl::~ProfileImpl() {
     default_request_context_ = NULL;
   }
 
+  if (bookmark_bar_model_.get()) {
+    // It's possible that bookmarks haven't loaded and history is waiting for
+    // bookmarks to complete loading. In such a situation history can't
+    // shutdown. To break the deadlock we tell BookmarkModel it's about to be
+    // deleted so that it can release the signal history is waiting on, allowing
+    // history to shutdown. In such a scenario history sees an incorrect view of
+    // bookmarks, but it's better than a deadlock.
+    bookmark_bar_model_->Cleanup();
+  }
   // HistoryService may call into the BookmarkModel, as such we need to
   // delete HistoryService before the BookmarkModel. The destructor for
   // HistoryService will join with HistoryService's backend thread so that