query_row segfaults

[cholcombe973]

query_row seems to segfault for me on the prepare line: https://github.com/jgallagher/rusqlite/blob/bf8c495b69859eea85a2e0b161b52dfe775a0641/src/lib.rs#L653. I'm walking through it with gdb and i'll have more info posted as I figure it out. I'm using the ~0.7 series of rusqlite

[cholcombe973]

I added some println statements to see if maybe the db connection was null or if the statement length wasn't right. Nothing obvious is coming up. This is the query that is breaking. When I execute it from the sqlite CLI it returns nothing.

path="/home/ubuntu/test/test1" mtime=1479232483 nsec=800923063 size=0
db: 0x7fcdaad82008
len_with_nul: 84
sql: SELECT blocks FROM mtime_cache WHERE path=? AND mtime=? AND mtime_nsec=? AND size=?

[cholcombe973]

Here's the backtrace:

#0  sqlite3WhereClauseClear (pWC=0x7fffea45f560) at sqlite3.c:123127
#1  0x00007fffee1cc5b1 in whereInfoFree (db=0x7fffea582008, pWInfo=0x7fffea45f408) at sqlite3.c:125022
#2  0x00007fffee20c044 in sqlite3Select (pParse=pParse@entry=0x7fffea454808, p=<optimized out>, 
    pDest=pDest@entry=0x7fffffff2a30) at sqlite3.c:115416
#3  0x00007fffee237bde in yy_reduce (yyruleno=111, yypParser=0x7fffea465008) at sqlite3.c:130315
#4  sqlite3Parser (yyp=yyp@entry=0x7fffea465008, yymajor=yymajor@entry=1, yyminor=..., 
    pParse=pParse@entry=0x7fffea454808) at sqlite3.c:331
#5  0x00007fffee23b9f0 in sqlite3RunParser (pParse=pParse@entry=0x7fffea454808, 
    zSql=zSql@entry=0x7fffea589300 "SELECT blocks FROM mtime_cache WHERE path=? AND mtime=? AND mtime_nsec=? AND size=?", pzErrMsg=pzErrMsg@entry=0x7fffffff2b60) at sqlite3.c:132342
#6  0x00007fffee23c082 in sqlite3Prepare (db=db@entry=0x7fffea582008, 
    zSql=zSql@entry=0x7fffea589300 "SELECT blocks FROM mtime_cache WHERE path=? AND mtime=? AND mtime_nsec=? AND size=?", nBytes=nBytes@entry=84, saveSqlFlag=saveSqlFlag@entry=1, pReprepare=pReprepare@entry=0x0, 
    ppStmt=ppStmt@entry=0x7fffffff2da8, pzTail=0x0) at sqlite3.c:109991
#7  0x00007fffee23c40a in sqlite3LockAndPrepare (db=0x7fffea582008, 
    zSql=0x7fffea589300 "SELECT blocks FROM mtime_cache WHERE path=? AND mtime=? AND mtime_nsec=? AND size=?", 
    nBytes=84, saveSqlFlag=1, pOld=0x0, ppStmt=0x7fffffff2da8, pzTail=0x0) at sqlite3.c:110083
#8  0x00007fffee23c6e6 in sqlite3_prepare_v2 (db=<optimized out>, zSql=<optimized out>, nBytes=<optimized out>, 
    ppStmt=<optimized out>, pzTail=<optimized out>) at sqlite3.c:110159
#9  0x00005555556ae20e in rusqlite::{{impl}}::prepare (sql=..., self=<optimized out>, conn=<optimized out>)
    at /home/chris/repos/rusqlite/src/lib.rs:665

[gwenn]

Do you know which version of SQLite you are using (the one rusqlite is linked to) ?
You can call println!("{:?}", libsqlite3_sys::sqlite3_version) or SELECT sqlite_version().
Thanks.

[cholcombe973]

I believe it's this:

ii  libsqlite3-0:amd64                   3.11.0-1ubuntu1                   amd64        SQLite 3 shared library
ii  libsqlite3-0-dbg                     3.11.0-1ubuntu1                   amd64        SQLite 3 debugging symbols
ii  libsqlite3-dev:amd64                 3.11.0-1ubuntu1                   amd64        SQLite 3 development files

[gwenn]

Why pWC->a is null (sqlite3.c:123127) ?
Maybe an allocation problem in whereClauseInsert ?

[cholcombe973]

I'm not sure if the problem is my FFI Ceph bindings I created or the sqlite bindings. Yeah the pWC->a null is very strange. It could be that my bindings are messing something up and sqlite is blowing up because of it or maybe my stuff isn't related. I can't tell yet.

[cholcombe973]

Ok we can close this issue. I tracked it down with valgrind. My library was using some bogus pointers and it was causing sqlite to blow up. There's no problem with the sqlite library :)