Sorry for long message, but this is required to explain my point.
Message is intended mainly to SQLite developers according new workflow for 
announcing bug candidates; regular users espacially those not using modules may 
skip it.

It looks like virtual tables' interface do not allow for doing certain things, 
even if they are legal and coded correctly.
E.g. opening other sqlite files within xFilter() or xOpen(), ... functions.
I cut down my case to the bare minimum and produced seg. fault by simple 
modifications in following sqlite files: 
src/test8.c, test/vtab1.test.
Change in test8.c is to make 'echo' module grab data from table in ANOTHER 
sqlite database instead of from THIS database (like in original 
implementation).
Change in vtab1.test is to accomodate test cases to change in test8.c.

$ diff sqlite-3.6.20-BUG/src/test8.c sqlite-3.6.20-ORIGINAL/src/test8.c
93d92
<   sqlite3      *pDb;            /* Database connection */
572,574d570
<   if (pCur->pDb)
<     sqlite3_close(pCur->pDb);
<   pCur->pDb = 0;
677,680c673
<   if (pCur->pDb)
<     sqlite3_close(pCur->pDb);
<   sqlite3_open("/tmp/test.db", &pCur->pDb);
<   sqlite3 *db = pCur->pDb;
---
>   sqlite3 *db = pVtab->db;

$ diff sqlite-3.6.20-BUG/test vtab1.test sqlite-3.6.20-ORIGINAL/test/vtab1.test
333,337d332
< file delete -force "/tmp/test.db"
< file delete -force "/tmp/test.db-journal"
< sqlite3 dbTest "/tmp/test.db"
< dbTest eval {CREATE TABLE IF NOT EXISTS treal(a INTEGER, b INTEGER, c)}
< dbTest eval {CREATE INDEX IF NOT EXISTS treal_idx ON treal(b)}
347,349d341
< dbTest eval {INSERT INTO treal VALUES(1, 2, 3)}
< dbTest eval {INSERT INTO treal VALUES(4, 5, 6)}
< dbTest close

After applying those changes and recompiling, make test finish as follows (on 
Debian 5.0.3 / i386):
vtab1-4.3... Ok
vtab1-4.4... Ok
vtab1-4.3...*** glibc detected *** ./testfixture: free(): invalid pointer: 
0x08d7a090 ***
======= Backtrace: =========
/lib/i686/cmov/libc.so.6[0x4019a624]
/lib/i686/cmov/libc.so.6(cfree+0x96)[0x4019c826]
./testfixture[0x8068da0]
./testfixture[0x8087fdb]
./testfixture[0x8091f32]
./testfixture[0x80b1591]
./testfixture[0x80b1e88]
./testfixture[0x8063fd0]
./testfixture[0x8066adf]
/usr/lib/libtcl8.4.so.0(TclEvalObjvInternal+0x326)[0x40057926]
/usr/lib/libtcl8.4.so.0(Tcl_EvalEx+0x43b)[0x4005861b]
/usr/lib/libtcl8.4.so.0(Tcl_EvalObjEx+0x78)[0x40058a68]
/usr/lib/libtcl8.4.so.0(Tcl_UplevelObjCmd+0xfe)[0x400b3eee]
/usr/lib/libtcl8.4.so.0(TclEvalObjvInternal+0x326)[0x40057926]
/usr/lib/libtcl8.4.so.0[0x400817cf]
/usr/lib/libtcl8.4.so.0(TclCompEvalObj+0x9f)[0x4007f90f]
/usr/lib/libtcl8.4.so.0(TclObjInterpProc+0x27d)[0x400b440d]
/usr/lib/libtcl8.4.so.0(TclEvalObjvInternal+0x326)[0x40057926]
/usr/lib/libtcl8.4.so.0[0x400817cf]
/usr/lib/libtcl8.4.so.0(TclCompEvalObj+0x9f)[0x4007f90f]
/usr/lib/libtcl8.4.so.0(TclObjInterpProc+0x27d)[0x400b440d]
/usr/lib/libtcl8.4.so.0(TclEvalObjvInternal+0x326)[0x40057926]
/usr/lib/libtcl8.4.so.0(Tcl_EvalEx+0x43b)[0x4005861b]
/usr/lib/libtcl8.4.so.0(Tcl_EvalObjEx+0x78)[0x40058a68]
/usr/lib/libtcl8.4.so.0(Tcl_UplevelObjCmd+0xfe)[0x400b3eee]
/usr/lib/libtcl8.4.so.0(TclEvalObjvInternal+0x326)[0x40057926]
/usr/lib/libtcl8.4.so.0[0x400817cf]
/usr/lib/libtcl8.4.so.0(TclCompEvalObj+0x9f)[0x4007f90f]
/usr/lib/libtcl8.4.so.0(TclObjInterpProc+0x27d)[0x400b440d]
/usr/lib/libtcl8.4.so.0(TclEvalObjvInternal+0x326)[0x40057926]
/usr/lib/libtcl8.4.so.0(Tcl_EvalEx+0x43b)[0x4005861b]
/usr/lib/libtcl8.4.so.0(Tcl_FSEvalFile+0x1e2)[0x4009d5c2]
/usr/lib/libtcl8.4.so.0(Tcl_SourceObjCmd+0x56)[0x40066746]
/usr/lib/libtcl8.4.so.0(TclEvalObjvInternal+0x326)[0x40057926]
/usr/lib/libtcl8.4.so.0[0x400817cf]
/usr/lib/libtcl8.4.so.0(TclCompEvalObj+0x9f)[0x4007f90f]
/usr/lib/libtcl8.4.so.0(Tcl_EvalObjEx+0xc4)[0x40058ab4]
/usr/lib/libtcl8.4.so.0(Tcl_ForeachObjCmd+0x559)[0x4005f9f9]
/usr/lib/libtcl8.4.so.0(TclEvalObjvInternal+0x326)[0x40057926]
/usr/lib/libtcl8.4.so.0(Tcl_EvalEx+0x43b)[0x4005861b]
/usr/lib/libtcl8.4.so.0(Tcl_FSEvalFile+0x1e2)[0x4009d5c2]
/usr/lib/libtcl8.4.so.0(Tcl_SourceObjCmd+0x56)[0x40066746]
/usr/lib/libtcl8.4.so.0(TclEvalObjvInternal+0x326)[0x40057926]
/usr/lib/libtcl8.4.so.0(Tcl_EvalEx+0x43b)[0x4005861b]
/usr/lib/libtcl8.4.so.0(Tcl_FSEvalFile+0x1e2)[0x4009d5c2]
/usr/lib/libtcl8.4.so.0(Tcl_EvalFile+0x41)[0x4009c191]
./testfixture[0x80630db]
/lib/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0x40142455]
./testfixture[0x804a7c1]
======= Memory map: ========
08048000-080d8000 r-xp 00000000 08:17 
18612471   
/home/grzegorz-deb/Pobrane/Source/Internet/sqlite.org/sqlite-3.6.20/testfixture
080d8000-080da000 rw-p 0008f000 08:17 
18612471   
/home/grzegorz-deb/Pobrane/Source/Internet/sqlite.org/sqlite-3.6.20/testfixture
080da000-080e1000 rw-p 080da000 00:00 0
08cd9000-08d81000 rw-p 08cd9000 00:00 0          [heap]
40000000-4001a000 r-xp 00000000 08:12 7692962    /lib/ld-2.7.so
4001a000-4001c000 rw-p 0001a000 08:12 7692962    /lib/ld-2.7.so
4001c000-4001d000 r-xp 4001c000 00:00 0          [vdso]
4001d000-4001f000 rw-p 4001d000 00:00 0
4001f000-40026000 r--s 00000000 08:12 
6419197    /usr/lib/gconv/gconv-modules.cache
40026000-40032000 r-xp 00000000 08:12 7693004    /lib/libgcc_s.so.1
40032000-40033000 rw-p 0000b000 08:12 7693004    /lib/libgcc_s.so.1
40033000-400dd000 r-xp 00000000 08:12 6580256    /usr/lib/libtcl8.4.so.0
400dd000-400e7000 rw-p 000a9000 08:12 6580256    /usr/lib/libtcl8.4.so.0
400e7000-400e8000 rw-p 400e7000 00:00 0
400e8000-400ea000 r-xp 00000000 08:12 7727041    /lib/i686/cmov/libdmake: *** 
[test] Przerwane

=================================================
I tried to debug, but problem is in memory allocations somewhere in the heart 
of 
sqlite query processing loops, so need more expertise in sqlite internals.
Here is what I know for now:
- Obvously problem is not related to TCL interface, it happens also with other 
interfaces.
- I noticed that crash is somehow related to sqlite3_step() calls inside 
echoNext(). I.e. if I do not grab all records from query (loop untill 
sqlite3_step() returns SQLITE_DONE), but break earlier, than seg. fault do not 
happen. Although seg. fault happens not immadiately after last sqlite3_step() 
call but later during db closing procedures.
- Seg. fault happens actually on following call (amalgamation release):
static void closeAllCursors(Vdbe *p){
// . . . 
  if( p->aMem ){
    releaseMemArray(&p->aMem[1], p->nMem); // SEG. FAULT
  }
}
- I was hit by this problem in 2.6.18, and, no change in .19 and .20 versions.

I'm currently stuck on this issue, and without opening external databases 
within 
my modules implementation, whole design of my application goes to rubish.
As you can see my moidifications are very simple, so I'm pretty sure that 
problem is in quite fresh modules' interface implementation.
I'd very appraciated if anybody from sqlite developers team could help resolve 
this issue.
I will continue investigating - if have more information - will share.

I attach 2 modified files (compare with 3.6.20 sources).

Best Regards,
Grzegorz W.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to