"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