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 sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users