aboutsummaryrefslogtreecommitdiff
path: root/src
diff options
context:
space:
mode:
authordrh <drh@noemail.net>2018-06-08 19:13:57 +0000
committerdrh <drh@noemail.net>2018-06-08 19:13:57 +0000
commitf3cd0c82dfc744e446203c89c7152380f85da5d5 (patch)
treea727c9fe46c53213ced938e556ae784fe4901a70 /src
parent83193d0133328a28dbd4d4bbd1f9747158d253a2 (diff)
downloadsqlite-f3cd0c82dfc744e446203c89c7152380f85da5d5.tar.gz
sqlite-f3cd0c82dfc744e446203c89c7152380f85da5d5.zip
Fix an assert() that can be false for a corrupt database and a strange query
that uses a recursive SQL function to delete content from a corrupt database file while it is being queried. FossilOrigin-Name: 99057383acc8f92093530e216c621d40386a06fe98131ff0af6df524d80a6410
Diffstat (limited to 'src')
-rw-r--r--src/btree.c11
1 files changed, 10 insertions, 1 deletions
diff --git a/src/btree.c b/src/btree.c
index 80b05d36c..a17fbbf53 100644
--- a/src/btree.c
+++ b/src/btree.c
@@ -5589,7 +5589,16 @@ static SQLITE_NOINLINE int btreeNext(BtCursor *pCur){
pPage = pCur->pPage;
idx = ++pCur->ix;
- assert( pPage->isInit );
+ if( !pPage->isInit ){
+ /* The only known way for this to happen is for there to be a
+ ** recursive SQL function that does a DELETE operation as part of a
+ ** SELECT which deletes content out from under an active cursor
+ ** in a corrupt database file where the table being DELETE-ed from
+ ** has pages in common with the table being queried. See TH3
+ ** module cov1/btree78.test testcase 220 (2018-06-08) for an
+ ** example. */
+ return SQLITE_CORRUPT_BKPT;
+ }
/* If the database file is corrupt, it is possible for the value of idx
** to be invalid here. This can only occur if a second cursor modifies