Issue Overview: Schema Manipulation Triggers editPage Assertion Failure

The core issue arises when executing a sequence of SQL operations that involve creating and modifying multiple tables, indexes, and virtual tables while applying aggressive database configuration settings. The assertion failure occurs in SQLite’s editPage function at line 76415 of the codebase, triggered during page modification operations. This function is part of SQLite’s B-tree module responsible for modifying database pages during write operations. The assertion assert(0) indicates an impossible code path was reached due to unexpected database state conditions.

Three critical factors converge here:

1. Schema Complexity: 15+ table creations with mixed constraints (UNIQUE, REFERENCES, generated columns)
2. Storage Configuration: Aggressive max_page_count=2 setting with incremental auto_vacuum
3. Data Operations: Large blob inserts (70KB zeroblob) and recursive CTE inserts with 1,001 rows

The error manifests during vacuum operations and schema changes that require page reorganization. The assertion acts as a canary for deeper issues in page management logic when handling constrained storage with complex object relationships.

Possible Causes: Page Management Conflicts Under Constrained Configuration

1. Page Allocation Contention with max_page_count=2

The PRAGMA max_page_count=2 limits database growth to 2 pages (1KB total with 512-byte pages). This directly conflicts with:

• 70KB zeroblob insertion requiring 140+ pages
• Recursive CTE inserting 1,001 rows into t4
• Multiple index creations requiring separate storage

SQLite’s page allocation subsystem becomes constrained, leading to edge cases in:

• Overflow page handling for large blobs
• Free page list management during VACUUM
• B-tree page splits during index creation

2. Virtual Table/Module Conflicts

Two virtual table creations appear problematic:

CREATE VIRTUAL TABLE v0 USING z0000000( R0000); -- Invalid module
CREATE VIRTUAL TABLE v00 USING fts4(); -- Valid FTS4

The z0000000 module doesn’t exist, causing incomplete virtual table initialization. When combined with FTS4 tables and subsequent schema changes, this creates undefined behavior in:

• Schema version tracking
• Page cache invalidation
• Transaction journal management

3. Constraint Validation Race Conditions

Several table definitions push SQLite’s constraint system:

CREATE TABLE n0000(s0000 UNIQUE AS (0), x00000000 REFERENCES n000(n000));
CREATE UNIQUE INDEX i0 ON t1(0, 0);

Generated columns with uniqueness constraints and self-referential foreign keys create circular dependencies that may not be fully resolved during schema modification. The DELETE FROM t4 and DROP TABLE t4 operations on non-existent tables suggest schema corruption prior to the assertion failure.

Troubleshooting Steps, Solutions & Fixes

Phase 1: Isolate the Failure Context

Step 1: Reproduce with Minimal Configuration
Remove all non-essential SQL statements while maintaining failure conditions:

.open :memory:
PRAGMA page_size=512;
PRAGMA auto_vacuum=incremental;
PRAGMA max_page_count=2;
CREATE TABLE a(b,c,PRIMARY KEY(c));
INSERT INTO a VALUES(0,zeroblob(70000)); -- Forces overflow pages
CREATE TABLE t4(a,b);
WITH RECURSIVE c(x) AS (VALUES(0) UNION SELECT x+1 FROM c LIMIT 1000)
INSERT INTO t4 SELECT x,0 FROM c; -- Exceeds max_page_count
VACUUM; -- Triggers page reorganization

Step 2: Enable Detailed Logging
Recompile SQLite with additional diagnostics:

export CFLAGS="-DSQLITE_DEBUG=1 -DSQLITE_DIRECT_OVERFLOW_READ"

Add callback for page change tracking:

sqlite3_config(SQLITE_CONFIG_LOG, 
  [](void*, int code, const char* msg){
    if(code == SQLITE_NOTICE) std::cerr << "[LOG] " << msg << "\n";
  }, nullptr);

Step 3: Analyze Page States Pre-Failure
Use sqlite3_analyzer tool before vacuum operations:

SELECT pgno, freeness FROM sqlite_dbpage;
SELECT * FROM sqlite_schema WHERE type='table';

Phase 2: Address Page Management Issues

Fix 1: Handle max_page_count/Auto-Vacuum Conflicts
When using incremental auto_vacuum with max_page_count, SQLite may fail to properly maintain the freelist. Modify btree.c to add boundary checks in balance_nonroot():

if( pPage->nFree < 0 ){
  sqlite3_log(SQLITE_CORRUPT, "Negative free page count");
  return SQLITE_CORRUPT_BKPT;
}

Fix 2: Overflow Page Allocation Guardrails
In pager.c, add overflow chain validation before editPage operations:

static int checkOverflowChain(PgHdr *pPg){
  Pgno pgno = pPg->pgno;
  while( pgno ){
    if( pgno > sqlite3BtreeLastPage(pBt) ){
      return SQLITE_CORRUPT;
    }
    // ... existing checks ...
  }
}

Phase 3: Schema Validation Enhancements

Solution 1: Virtual Table Initialization Order
Modify vtab.c to defer virtual table initialization until all schema changes are committed:

int sqlite3VtabBeginParse(){
  if( !db->init.imposterTable ){
    db->nVtabLock++; // Prevent concurrent schema changes
  }
}

Solution 2: Constraint Cycle Detection
Enhance the foreign key/constraint resolver in build.c with cycle detection:

void sqlite3CreateForeignKey(
  Parse *pParse,
  ExprList *pFromCol,
  Token *pTo,
  ExprList *pToCol,
  int flags
){
  if( pParse->nFkCycle > SQLITE_MAX_FK_DEPTH ){
    sqlite3ErrorMsg(pParse, "foreign key cycle detected");
  }
  pParse->nFkCycle++;
}

Final Mitigation Strategy

1. Remove max_page_count pragma or set to reasonable value (>100)
2. Replace invalid virtual table modules with valid implementations
3. Separate large blob operations from recursive CTE inserts
4. Run schema validation checks before vacuum:

PRAGMA integrity_check;
PRAGMA foreign_key_check;

5. Use WAL journal mode instead of "o" (invalid mode specifier)

These solutions address both the immediate assertion failure and underlying page management vulnerabilities exposed by the test case. The fixes require careful validation of page allocation states during constrained storage operations and enhanced schema change atomicity when dealing with virtual tables and complex constraints.