> > ---- Mensaje original ---- > De: Dan Kennedy <danielk1977 at gmail.com> > Para: sqlite-users at mailinglists.sqlite.org > Fecha: Fri, 11 Dec 2015 22:54:45 +0700 > Asunto: Re: [sqlite] Problem when upgrading from FTS3/4 > toFTS5modules(revisited) > >>> >>>> 1a.- Delete the previous table. >>>> DROP TABLE IF EXIST ftsm >>>> >>>> This scheme work ok with the FST3/4 modules, but compiling with FTS5 gives >>>> an erroro in 1a: "database disk image is malformed". >>>> >>>> Note that in previous attemps I believed that the problem was into try to >>>> delete a ftsm table build with the previous modules, but the error happen >>>> when trying delete a table build with the FTS5 module. >>>> >>>> ... >>>>>> Some clues? >>>>> Not really sure why it might fail there. Can you post the entire >>>>> database schema (results of "SELECT * FROM sqlite_master" or the output >>>>> of the .schema shell tool command)? >>>>> >>>> Dan: >>>> >>>> Here is the schema: >>> That all looks Ok. >>> >>> If you use the shell tool to execute the "DROP TABLE IF EXISTS ftsm" >>> command does it report an error as well? >>> >> Dan: >> >> Surprisingly, the shell does not complain when using the same query, and >> indeed, drop the table. >> >> Yeah, I also believe that the problem is in my roof, although that code has >> been behaving Ok from ages with the FTS3/4 modules (only changes some >> directives in other places of the code). >> >> Any way, when running again the code when the table has been previously >> erased (with the shell), the routine works without complaint (executes the >> query correctly), and despite the warning, the rest of the app behaves >> correctly and the queries related with the search works fine. >> >> When the table exist, the debugger shows that sqlite3_prepare_v2() ends Ok, >> but sqlite3_step() ends with error 11. > >Are you able to compile a debugging build of SQLite and set a breakpoint >in sqlite3CorruptError()? > >Assuming the breakpoint is triggered within the DROP TABLE IF EXISTS >statement (pretty good chance), the stack trace will tell us more about >the form of corruption SQLite thinks it has found. >
Dan: I managed a breakpoint int the requested function, and can tell that it has been called twice inside the sqlite3_step() function before it returns. Here you have the call's stack: First call of sqlite3CorrupError() lineno == 56209 sqlite3CorruptError(int lineno) Line 133961 decodeFlags(MemPage * pPage, int flagByte) Line 56209 btreeInitPage(MemPage * pPage) Line 56251 getAndInitPage(BtShared * pBt, unsigned int pgno, MemPage * * ppPage, BtCursor * pCur, int bReadOnly) Line 56495 clearDatabasePage(BtShared * pBt, unsigned int pgno, int freePageFlag, int * pnChange) Line 62907 sqlite3BtreeClearTable(Btree * p, int iTable, int * pnChange) Line 62970 btreeDropTable(Btree * p, unsigned int iTable, int * piMoved) Line 63028 sqlite3BtreeDropTable(Btree * p, int iTable, int * piMoved) Line 63111 sqlite3VdbeExec(Vdbe * p) Line 77954 sqlite3Step(Vdbe * p) Line 71546 sqlite3_step(sqlite3_stmt * pStmt) Line 71608 sqlite3_exec(sqlite3 * db, const char * zSql, int (void *, int, char * *, char * *) * xCallback, void * pArg, char * * pzErrMsg) Line 103955 fts5ExecPrintf(sqlite3 * db, char * * pzErr, const char * zFormat, ...) Line 180863 sqlite3Fts5DropAll(Fts5Config * pConfig) Line 180876 fts5DestroyMethod(sqlite3_vtab * pVtab) Line 178532 sqlite3VtabCallDestroy(sqlite3 * db, int iDb, const char * zTab) Line 117587 sqlite3VdbeExec(Vdbe * p) Line 79084 sqlite3Step(Vdbe * p) Line 71546 sqlite3_step(sqlite3_stmt * pStmt) Line 71608 Secon call of sqlite3CorrupError() lineno == 56251 sqlite3CorruptError(int lineno) Line 133961 btreeInitPage(MemPage * pPage) Line 56251 getAndInitPage(BtShared * pBt, unsigned int pgno, MemPage * * ppPage, BtCursor * pCur, int bReadOnly) Line 56495 ... Rest the same... Note that the line numbers can be slightly greater than the ones in the original file (SQLite 3.9.1) because the inclusion of some comments. As I can reproduce the problem as needed, In case of interest, I can try to provide any intermediate value inside the stack. Thanks again for yours attention. -- Adolfo J. Millan
