On 6/8/17, Bob Friesenhahn <[email protected]> wrote: > On Thu, 8 Jun 2017, D. Richard Hipp wrote: > >> A bug in the auto_vacuum logic for SQLite versions 3.16.0 through >> 3.19.2 can (rarely) lead to database corruption. SQLite version >> 3.19.3 has just been released to fix this bug. > > Does 'pragma integrity_check' reliably detect this database > corruption?
yes. > > We are using 3.17.0 (under Linux on 32-bit MIPS) and have been getting > a database is corrupted report (as reported earlier to this list), > with this call backtrace: The line numbers in the backtrace below do not align with version 3.17.0. Have you made proprietary modifications to the sqlite3.c source file? The SHA1 hash of the sqlite3.c source file should be cc7d708bb073c44102a59ed63ce6142da1f174d1. What do you get? > > #4 0x77ce1754 in renderLogMsg (ap=0x777a4638, zFormat=<optimized out>, > iErrCode=11) at sqlite3.c:26045 > #5 sqlite3_log (iErrCode=11, zFormat=<optimized out>) at sqlite3.c:26055 > #6 0x77ce17c0 in reportError (zType=0x77d5be94 "database corruption", > lineno=<optimized out>, iErr=11) at sqlite3.c:142724 > #7 sqlite3CorruptError (lineno=<optimized out>) at sqlite3.c:11658 > #8 0x77cfed84 in getAndInitPage (pBt=0xbeffd8, pgno=20, ppPage=0xc02a98, > pCur=0x0, bReadOnly=2) at sqlite3.c:60910 > #9 0x77cffdb8 in moveToRoot (pCur=0xc02a20) at sqlite3.c:63772 > #10 0x77d01df4 in sqlite3BtreeMovetoUnpacked (pCur=0xc02a20, pIdxKey=0x0, > intKey=<optimized out>, biasRight=0, pRes=0x777a4758) at sqlite3.c:64027 > #11 0x77d02a34 in handleDeferredMoveto (p=0xc02980) at sqlite3.c:74232 > #12 0x77d2342c in sqlite3VdbeCursorMoveto (piCol=<synthetic pointer>, > pp=<synthetic pointer>) at sqlite3.c:74299 > #13 sqlite3VdbeExec (p=0xbf51e0) at sqlite3.c:14953 > #14 0x77d2af60 in sqlite3Step (p=0xbf51e0) at sqlite3.c:76450 > #15 sqlite3_step (pStmt=0xbf51e0) at sqlite3.c:10975 > #16 sqlite3_step (pStmt=0xbf51e0) at sqlite3.c:10962 > > When this happens, 'pragma integrity_check' never finds a problem with > the database. Regardless, it seems that once the problem starts > happening, it recurs given the same starting database. The starting > database is already a product of VACCUM before any other software > starts to use it. > > Bob > -- > Bob Friesenhahn > [email protected], http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ > _______________________________________________ > sqlite-users mailing list > [email protected] > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp [email protected] _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
