Hi everybody,
While testing some database upgrade function of mine, I ran into a
segmentation fault. I started looking at the possible cause in my
code, but I soon realized the crash would only happen using SQLite
3.7.7 or 3.7.8. If I use 3.7.6 or lower, things go safely.
Since I am not familiar with SQLite's internals, I have run the thing
under Valgrind and GDB to get some backtraces. Here is Valgrind's
report:
==27928== Invalid read of size 4
==27928== at 0x646251: sqlite3Fts3PendingTermsFlush (sqlite3.c:124996)
==27928== by 0x63A2A8: fts3SyncMethod (sqlite3.c:117025)
==27928== by 0x63A983: fts3SavepointMethod (sqlite3.c:117332)
==27928== by 0x6239C5: sqlite3VtabSavepoint (sqlite3.c:100182)
==27928== by 0x5E9F07: sqlite3VdbeExec (sqlite3.c:66431)
==27928== by 0x5E40D8: sqlite3Step (sqlite3.c:61954)
==27928== by 0x5E42B9: sqlite3_step (sqlite3.c:62027)
==27928== by 0x5B3BC3: SQLite::Query::exec() (Query.cc:179)
==27928== by 0x5B3D80: SQLite::Query::exec(QString const&) (Query.cc:230)
==27928== by 0x590DF5: update8to9(SQLite::Query&) (Database.cc:206)
==27928== by 0x59128A: Database::updateUserDB(int) (Database.cc:262)
==27928== by 0x5914CD: Database::checkUserDB() (Database.cc:297)
==27928== Address 0x150 is not stack'd, malloc'd or (recently) free'd
==27928==
==27928==
==27928== Process terminating with default action of signal 11 (SIGSEGV)
==27928== Access not within mapped region at address 0x150
==27928== at 0x646251: sqlite3Fts3PendingTermsFlush (sqlite3.c:124996)
==27928== by 0x63A2A8: fts3SyncMethod (sqlite3.c:117025)
==27928== by 0x63A983: fts3SavepointMethod (sqlite3.c:117332)
==27928== by 0x6239C5: sqlite3VtabSavepoint (sqlite3.c:100182)
==27928== by 0x5E9F07: sqlite3VdbeExec (sqlite3.c:66431)
==27928== by 0x5E40D8: sqlite3Step (sqlite3.c:61954)
==27928== by 0x5E42B9: sqlite3_step (sqlite3.c:62027)
==27928== by 0x5B3BC3: SQLite::Query::exec() (Query.cc:179)
==27928== by 0x5B3D80: SQLite::Query::exec(QString const&) (Query.cc:230)
==27928== by 0x590DF5: update8to9(SQLite::Query&) (Database.cc:206)
==27928== by 0x59128A: Database::updateUserDB(int) (Database.cc:262)
==27928== by 0x5914CD: Database::checkUserDB() (Database.cc:297)
And here is the GDB backtrace (using 3.7.8):
#0 0x0000000000646251 in sqlite3Fts3PendingTermsFlush (p=0x0) at
sqlite3.c:124996
#1 0x000000000063a2a9 in fts3SyncMethod (pVtab=0x0) at sqlite3.c:117025
#2 0x000000000063a984 in fts3SavepointMethod (pVtab=0x0, iSavepoint=0)
at sqlite3.c:117332
#3 0x00000000006239c6 in sqlite3VtabSavepoint (db=0x9bf4a8, op=0,
iSavepoint=0) at sqlite3.c:100182
#4 0x00000000005e9f08 in sqlite3VdbeExec (p=0x9b9ac8) at sqlite3.c:66431
#5 0x00000000005e40d9 in sqlite3Step (p=0x9b9ac8) at sqlite3.c:61954
#6 0x00000000005e42ba in sqlite3_step (pStmt=0x9b9ac8) at sqlite3.c:62027
Here the faulty is pVtab which should not be NULL from
fts3SavepointMethod, since it is unconditionally dereferenced.
fts3SavepointMethod is called through a function pointer from line
100182 which reads the following:
rc = xMethod(db->aVTrans[i]->pVtab, iSavepoint);
That's about all the information I can get for now. Compiling with
SQLITE_DEBUG=1 does not give anything more - it just crashes earlier
in fts3SavepointMethod because of an assert that dereferences pVtab. I
do not understand SQLite's code well, but it seems to me that a
virtual table function should not be called with a NULL virtual table
pointer anyway.
I wish I could send a code sample that reproduces the issue, but
unfortunately the case is rather big and complex. I will try to come
with a minimal program though. If there is anything more I can do to
help debugging, please let me know.
Thanks,
Alex.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
