[SQLite] Hack to touch page cache to debug slow connection close.

The shutdown-monitor has noted cases where sqlite3_close() is taking a
very long time to finish.  In reviewing the code, writes are committed
before the close is called, so there should be almost no I/O involved
(excepting perhaps unlocking the file?).  One hypothesis is that the
SQLite page cache, which is LRU, may have very old pages which have
been paged out.  This change touches them all, so if they are paged
out the crash should move to this code.

BUG=95527
TEST=Monitor crash in bug, see if it changes.


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

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

1 files changed, 14 insertions, 0 deletions

diff --git a/sql/connection.cc b/sql/connection.cc
index 0f2df97..bda1d26 100644
--- a/sql/connection.cc
+++ b/sql/connection.cc
@@ -111,6 +111,20 @@ void Connection::Close() {
   statement_cache_.clear();
   DCHECK(open_statements_.empty());
   if (db_) {
+    // TODO(shess): Some additional code to debug http://crbug.com/95527 .
+    // If you are reading this due to link errors or something, it can
+    // be safely removed.
+#if defined(HAS_SQLITE3_95527)
+    unsigned int nTouched = 0;
+    sqlite3_95527(db_, &nTouched);
+
+    // If a VERY large amount of memory was touched, crash.  This
+    // should never happen.
+    // TODO(shess): Pull this in.  It should be page_size * page_cache
+    // or something like that, 4M or 16M.  For now it's just to
+    // prevent optimization.
+    CHECK_LT(nTouched, 1000*1000*1000U);
+#endif
     sqlite3_close(db_);
     db_ = NULL;
   }