[sql] Diagnostic to track recovery crash.

There are some crashes happening in leafCursorCellDecode() which imply
that the leaf cursor is NULL.  AFAICT, this case is not possible.  Add
some code to verify whether the leaf cursor was NULL at the point it was
added to the virtual-table cursor.  If the crash moves, then there's
something wrong with leafCursorCreate(), if the crash stays in place,
there's something happening in the SQLite virtual table infrastructure.

BUG=326646

Review URL: https://codereview.chromium.org/109123002

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

1 files changed, 11 insertions, 0 deletions

diff --git a/third_party/sqlite/amalgamation/sqlite3.c b/third_party/sqlite/amalgamation/sqlite3.c
index eb1c517..91e98680 100644
--- a/third_party/sqlite/amalgamation/sqlite3.c
+++ b/third_party/sqlite/amalgamation/sqlite3.c
@@ -112080,6 +112080,17 @@ static int recoverOpen(sqlite3_vtab *pVTab, sqlite3_vtab_cursor **ppCursor){
   pCursor->pLeafCursor = pLeafCursor;
   pCursor->iEncoding = iEncoding;
 
+  // TODO(shess): http://crbug.com/326646 implies that pCursor->pLeafCursor is
+  // NULL here.  Auditing leafCursorCreate() and its callees, that is not
+  // possible.  If the crash moves to here, it is obviously happening, otherwise
+  // something in the caller is the problem.
+  if (pCursor->pLeafCursor->nPageSize != nPageSize) {
+    // This code should never be reached.
+    leafCursorDestroy(pLeafCursor);
+    sqlite3_free(pCursor);
+    return SQLITE_ERROR;
+  }
+
   *ppCursor = (sqlite3_vtab_cursor*)pCursor;
   return SQLITE_OK;
 }