Here is how it looks with debug symbols are on:
#0 0x28c4113e in memcpy () from /lib/libc.so.7
#1 0x08854c20 in sqlite3StrAccumAppend (p=0xfffe8548, z=0x2c3fffda
"vtb_enyqkyxs USING vtable_module_343", N=41) at sqlite3.c:21563
#2 0x087edf30 in sqlite3VXPrintf (pAccum=0xfffe8548, bFlags=1, fmt=0x892e543
"T", ap=0xfffe8610 "") at sqlite3.c:21439
#3 0x088077d5 in sqlite3VMPrintf (db=0x2c006788, zFormat=0x892e52d "CREATE
VIRTUAL TABLE %T", ap=0xfffe860c "xx") at sqlite3.c:21638
#4 0x087f815e in sqlite3MPrintf (db=0x2c006788, zFormat=0x892e52d "CREATE
VIRTUAL TABLE %T") at sqlite3.c:21654
#5 0x088759af in sqlite3VtabFinishParse (pParse=0x2c007688, pEnd=0x0) at
sqlite3.c:112383
#6 0x0885bb21 in yy_reduce (yypParser=0x2c1d1408, yyruleno=309) at
sqlite3.c:123403
#7 0x08856180 in sqlite3Parser (yyp=0x2c1d1408, yymajor=1, yyminor=...,
pParse=0x2c007688) at sqlite3.c:123629
#8 0x087fc289 in sqlite3RunParser (pParse=0x2c007688, zSql=0x2c3fffc0 "CREATE
VIRTUAL TABLE temp.vtb_enyqkyxs USING vtable_module_343", pzErrMsg=0xfffe8bc4)
at sqlite3.c:124466
#9 0x088bbc82 in sqlite3Prepare (db=0x2c006788, zSql=0x2c3fffc0 "CREATE
VIRTUAL TABLE temp.vtb_enyqkyxs USING vtable_module_343", nBytes=-1,
saveSqlFlag=1, pReprepare=0x0, ppStmt=0xfffe8d0c, pzTail=0xfffe8d10) at
sqlite3.c:103750
#10 0x087fb0ce in sqlite3LockAndPrepare (db=0x2c006788, zSql=0x2c3fffc0 "CREATE
VIRTUAL TABLE temp.vtb_enyqkyxs USING vtable_module_343", nBytes=-1,
saveSqlFlag=1, pOld=0x0, ppStmt=0xfffe8d0c, pzTail=0xfffe8d10) at
sqlite3.c:103842
#11 0x087fa504 in sqlite3_prepare_v2 (db=0x2c006788, zSql=0x2c3fffc0 "CREATE
VIRTUAL TABLE temp.vtb_enyqkyxs USING vtable_module_343", nBytes=-1,
ppStmt=0xfffe8d0c, pzTail=0xfffe8d10) at sqlite3.c:103918
#12 0x087fa01d in sqlite3_exec (db=0x2c006788, zSql=0x2c3fffc0 "CREATE VIRTUAL
TABLE temp.vtb_enyqkyxs USING vtable_module_343", xCallback=0x0, pArg=0x0,
pzErrMsg=0x0) at sqlite3.c:99345
#13 0x086588e7 in sqlite::StorageBase::exec_query (this=0x2c3ff640,
query=0x2c3fffc0 "CREATE VIRTUAL TABLE temp.vtb_enyqkyxs USING
vtable_module_343", quiet=false) at SqliteStorageBase.cpp:286
Interesting part is in frame #5
#5 0x088759af in sqlite3VtabFinishParse (pParse=0x2c007688, pEnd=0x0) at
sqlite3.c:112383
112383 zStmt = sqlite3MPrintf(db, "CREATE VIRTUAL TABLE %T",
&pParse->sNameToken);
(gdb) p pParse->sNameToken
$12 = {
z = 0x2c3fffda "vtb_enyqkyxs USING vtable_module_343",
n = 41
}
(gdb) p pParse->sNameToken.z + 40
$13 = 0x2c400002 <error: Cannot access memory at address 0x2c400002>
As you can see, token size is invalid: 41. This causes memcpy() down at #0 to
access invalid, unmapped address.
Hopefully it is only read overflow so the only consequence is just an
occasional Segmentation fault when allocated
piece of string is at the specific place: near the end of the page in front of
unmapped page.
Should I fill a bug report?
Is there a way to work this around?
Like append many spaces a the end of query?
Or maybe the problem is in absence of ';' at the end of query?
Meantime I'll try both of these cases.
> We observe very similar problem.
>
> #1 0x087ec9f7 in sqlite3VXPrintf ()
> #2 0x087f816d in sqlite3MPrintf ()
> #3 0x088781e5 in sqlite3VtabFinishParse ()
> #4 0x0885190f in yy_reduce ()
> #5 0x0884d4d8 in sqlite3Parser ()
> #6 0x087fc0ce in sqlite3RunParser ()
> #7 0x088aa396 in sqlite3Prepare ()
> #8 0x087fae18 in sqlite3LockAndPrepare ()
> #9 0x087f9a88 in sqlite3_exec ()
> #10 0x086588a7 in sqlite::StorageBase::exec_query (this=0x2c2a47c0,
> query=0x2c7fffc0 "CREATE VIRTUAL TABLE temp.vtb_wayxzmbo USING
> vtable_module_344", quiet=false) at SqliteStorageBase.cpp:286
>
> It always crashes when "CREATE VIRTUAL TABLE ..." is being executed, always
> with the same backtrace.
> I spent many days reviewing and testing my code to eliminate possible cause
> but so far I see nothing wrong with it.
> Probability of this crash is so very low so that problem can be reproduced
> only on hi loaded production servers.
> (Where such virtual tables are created and dropped millions of times during a
> day)
>
> I am going to compile sqlite without optimizations and with debug symbols and
> wait for a crash
> to try and track the root of the problem from within sqlite.
>
> Though I doubt very much this is sqlite problem at all and not an incorrect
> vtable implementation on my side.
>
>
> SQLite version 3.8.6 2014-08-15 11:46:33
>
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users