"Jay A. Kreibich" <j...@kreibi.ch> writes:
> On Wed, Mar 07, 2012 at 08:58:27PM +0100, Steinar Midtskogen scratched on the
> wall:
>> I've created a module which will take a table as an argument. In
>> Xconnect it will run a query on that table. Then I accidently used
>> the name of the virtual table in the argument list:
>>
>> CREATE VIRTUAL TABLE v USING my_module(v);
>>
>> which seems to have triggered an infinite call loop. I suppose what's
>> going on is that when Xconnect
>
> It should be xCreate() if it is a new table.
Yes, probably. xCreate() and xConnect() are the same function. I
just happened to call it "connect".
> I doubt that is what is happening. More likely, the query is
> blocking in some way. SQLite would never automatically create a
> non-existent table you tried to access. How would it know what to
> create?
I was guessing this having looked at the call trace in gdb. It is:
#0 0x00007fd0ed98d8a3 in sqlite3VXPrintf (pAccum=Cannot access memory at
address 0x7ffff5644f08
) at sqlite3.c:19459
#1 0x00007fd0ed98f97a in sqlite3VMPrintf (db=0x60e030, zFormat=0x7fd0eda087bf
"%s", ap=0x7ffff5645120) at sqlite3.c:20096
#2 0x00007fd0ed98fa9a in sqlite3MPrintf (db=0x60e030, zFormat=0x7fd0eda087bf
"%s") at sqlite3.c:20112
#3 0x00007fd0ed9f4444 in vtabCallConstructor (db=0x60e030, pTab=0x6385e0,
pMod=0x61eae0, xConstruct=0x7fd0ec345470 <interpolate_connect>,
pzErr=0x7ffff56452c0) at sqlite3.c:101732
#4 0x00007fd0ed9f48e5 in sqlite3VtabCallConnect (pParse=0x19dd610,
pTab=0x6385e0) at sqlite3.c:101848
#5 0x00007fd0ed9d4b35 in sqlite3ViewGetColumnNames (pParse=0x19dd610,
pTable=0x6385e0) at sqlite3.c:82813
#6 0x00007fd0ed9e3fbd in sqlite3Pragma (pParse=0x19dd610, pId1=0x19dd938,
pId2=0x19dd958, pValue=0x19dd998, minusFlag=0) at sqlite3.c:92812
#7 0x00007fd0eda00cce in yy_reduce (yypParser=0x19dd8c0, yyruleno=257) at
sqlite3.c:110533
#8 0x00007fd0eda016af in sqlite3Parser (yyp=0x19dd8c0, yymajor=1, yyminor={z =
0x19dd603 ")", n = 1}, pParse=0x19dd610) at sqlite3.c:110915
#9 0x00007fd0eda024d7 in sqlite3RunParser (pParse=0x19dd610, zSql=0x19dd5f0
"PRAGMA table_info(x)", pzErrMsg=0x7ffff5645888) at sqlite3.c:111752
#10 0x00007fd0ed9e6b44 in sqlite3Prepare (db=0x60e030, zSql=0x19dd5f0 "PRAGMA
table_info(x)", nBytes=-1, saveSqlFlag=1, pReprepare=0x0,
ppStmt=0x7ffff5645a28, pzTail=0x0) at sqlite3.c:94079
#11 0x00007fd0ed9e6e4f in sqlite3LockAndPrepare (db=0x60e030, zSql=0x19dd5f0
"PRAGMA table_info(x)", nBytes=-1, saveSqlFlag=1, pOld=0x0,
ppStmt=0x7ffff5645a28, pzTail=0x0) at sqlite3.c:94171
#12 0x00007fd0ed9e7010 in sqlite3_prepare_v2 (db=0x60e030, zSql=0x19dd5f0
"PRAGMA table_info(x)", nBytes=-1, ppStmt=0x7ffff5645a28, pzTail=0x0)
at sqlite3.c:94246
#13 0x00007fd0ec34566e in interpolate_connect (db=0x60e030, pAux=<value
optimized out>, argc=<value optimized out>, argv=0x638580, ppVtab=0x19dd4c0,
pzErr=<value optimized out>) at extension-functions.c:447
#14 0x00007fd0ed9f44fa in vtabCallConstructor (db=0x60e030, pTab=0x6385e0,
pMod=0x61eae0, xConstruct=0x7fd0ec345470 <interpolate_connect>,
pzErr=0x7ffff5645b40) at sqlite3.c:101752
#15 0x00007fd0ed9f48e5 in sqlite3VtabCallConnect (pParse=0x19dc130,
pTab=0x6385e0) at sqlite3.c:101848
#16 0x00007fd0ed9d4b35 in sqlite3ViewGetColumnNames (pParse=0x19dc130,
pTable=0x6385e0) at sqlite3.c:82813
#17 0x00007fd0ed9e3fbd in sqlite3Pragma (pParse=0x19dc130, pId1=0x19dc458,
pId2=0x19dc478, pValue=0x19dc4b8, minusFlag=0) at sqlite3.c:92812
#18 0x00007fd0eda00cce in yy_reduce (yypParser=0x19dc3e0, yyruleno=257) at
sqlite3.c:110533
#19 0x00007fd0eda016af in sqlite3Parser (yyp=0x19dc3e0, yymajor=1, yyminor={z =
0x19dc123 ")", n = 1}, pParse=0x19dc130) at sqlite3.c:110915
#20 0x00007fd0eda024d7 in sqlite3RunParser (pParse=0x19dc130, zSql=0x19dc110
"PRAGMA table_info(x)", pzErrMsg=0x7ffff5646108) at sqlite3.c:111752
#21 0x00007fd0ed9e6b44 in sqlite3Prepare (db=0x60e030, zSql=0x19dc110 "PRAGMA
table_info(x)", nBytes=-1, saveSqlFlag=1, pReprepare=0x0,
ppStmt=0x7ffff56462a8, pzTail=0x0) at sqlite3.c:94079
#22 0x00007fd0ed9e6e4f in sqlite3LockAndPrepare (db=0x60e030, zSql=0x19dc110
"PRAGMA table_info(x)", nBytes=-1, saveSqlFlag=1, pOld=0x0,
ppStmt=0x7ffff56462a8, pzTail=0x0) at sqlite3.c:94171
#23 0x00007fd0ed9e7010 in sqlite3_prepare_v2 (db=0x60e030, zSql=0x19dc110
"PRAGMA table_info(x)", nBytes=-1, ppStmt=0x7ffff56462a8, pzTail=0x0)
at sqlite3.c:94246
#24 0x00007fd0ec34566e in interpolate_connect (db=0x60e030, pAux=<value
optimized out>, argc=<value optimized out>, argv=0x638580, ppVtab=0x19dbfe0,
pzErr=<value optimized out>) at extension-functions.c:447
#25 0x00007fd0ed9f44fa in vtabCallConstructor (db=0x60e030, pTab=0x6385e0,
pMod=0x61eae0, xConstruct=0x7fd0ec345470 <interpolate_connect>,
pzErr=0x7ffff56463c0) at sqlite3.c:101752
... and so on, until:
#42352 0x00007fd0ec34566e in interpolate_connect (db=0x60e030, pAux=<value
optimized out>, argc=<value optimized out>, argv=0x638580,
ppVtab=0x61d770, pzErr=<value optimized out>) at extension-functions.c:447
#42353 0x00007fd0ed9f44fa in vtabCallConstructor (db=0x60e030, pTab=0x6385e0,
pMod=0x61eae0, xConstruct=0x7fd0ec345470 <interpolate_connect>,
pzErr=0x63a418) at sqlite3.c:101752
#42354 0x00007fd0ed9f4af1 in sqlite3VtabCallCreate (db=0x60e030, iDb=0,
zTab=0x63a600 "x", pzErr=0x63a418) at sqlite3.c:101918
#42355 0x00007fd0ed9c2631 in sqlite3VdbeExec (p=0x63a3c0) at sqlite3.c:70507
#42356 0x00007fd0ed9b7b4c in sqlite3Step (p=0x63a3c0) at sqlite3.c:63043
#42357 0x00007fd0ed9b7d0b in sqlite3_step (pStmt=0x63a3c0) at sqlite3.c:63116
#42358 0x00000000004047b7 in shell_exec (db=0x60e030, zSql=0x63a380 "create
virtual table x using interpolate(x);",
xCallback=0x402e8c <shell_callback>, pArg=0x7ffff5e42d40,
pzErrMsg=0x7ffff5e42c18) at ./src/shell.c:1142
#42359 0x00000000004089d7 in process_input (p=0x7ffff5e42d40, in=0x0) at
./src/shell.c:2522
#42360 0x000000000040998f in main (argc=2, argv=0x7ffff5e44388) at
./src/shell.c:2972
My xCreate()/xConnect() is "interpolate_connect".
> What happens if you attempt to create a VT that references a
> non-existent table? Are you sure you're checking all the return
> values from the queires issued inside xCreate/xConnect?
Yes, pretty sure. And it does fail in the case of a non-existent
table.
> VTs are very advance pieces of code. SQLite provides very little
> protection from dumb code when you're interfacing at that low a
> level. Preventing dumb stuff is pretty much always up to the
> VT code.
I can easily check that the argument doesn't match argv[2], but if
it's still possible to get into a loop like this if virtual tables
refer to eachother, then I don't think it's possible to detect this in
the VT code.
--
Steinar
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
