Revert 110177 - Sync: Improve handling of database load failures

   
This failure path has not received a lot of testing until now.  Here are
the issues addressed by this patch:
    
- We usually check the return value of step() calls.  However, we do not
check the return value of prepare() calls, which are more likely to fail.
If they do fail, we will DCHECK() or go on to dereference an invalid
pointer in step().  This patch checks the return value of one particular
prepare statement, the one in CheckIntegrity().
    
- Disable DCHECKs on sqlite errors, DirectoryManager open failure,
and SyncManager initialization failure.  This will allow us to test these
error paths.
    
- Be careful in ShutdownOnSyncThread().  The directory will not be fully
intialized during shutdown if the database load failed.

- Add a ProfileSyncService unit test that simulates a load from an
unreadable database.  The harness had to be modified slightly to make
this possible.

- Remove a setup_for_test_mode_ flag in SyncManager::SyncInternal::Init.
I don't know what the original intent of this flag was.  However, I do
know that it prevents me from properly simulating a database load failure
and removing it seems to have no ill effects.

- Do not delete the database from DirectoryBackingStore.  If this code
were to get executed it would put us into an inconsistent state.  See
issue 103824.  However, it's unlikely this code would get executed.  If
the database were actually corrupt, we would DCHECK or de-reference an
invalid pointer on our way to this code because we don't check the
return value of the attempt to prepare an SQL statement in
DirectoryBackingStore::CheckIntegrity().
    
- Modify the DirectoryBackingStoreTest.Corruption unit test to expect the
new behaviour.

- Disable sync when backend initialize fails.  Such a failure could
be due to bad local state.  We don't know the actual cause because the
information is not available from the ProfileSyncService callback.  The
safe course of action is to clear our local sync state and try again
later.  It's the easiest way to get back to the most well travelled sync
initialization path.

BUG=103307, 103824
TEST=DirectoryBackingStoreTest.Corruption, ProfileSyncServiceTest.CorruptDatabase

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

TBR=rlarocque@chromium.org
Review URL: http://codereview.chromium.org/8570016

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

1 files changed, 3 insertions, 3 deletions

diff --git a/chrome/browser/sync/util/sqlite_utils.cc b/chrome/browser/sync/util/sqlite_utils.cc
index 7b75f0e..4cb6c4e 100644
--- a/chrome/browser/sync/util/sqlite_utils.cc
+++ b/chrome/browser/sync/util/sqlite_utils.cc
@@ -33,9 +33,9 @@ class DebugSQLErrorHandler: public VanillaSQLErrorHandler {
  public:
   virtual int HandleError(int error, sqlite3* db) {
     error_ = error;
-    LOG(ERROR) << "sqlite error " << error
-               << " " << sqlite3_errmsg(db)
-               << " db " << static_cast<void*>(db);
+    NOTREACHED() << "sqlite error " << error
+                 << " " << sqlite3_errmsg(db)
+                 << " db " << static_cast<void*>(db);
     return error;
   }
 };