On Nov 12, 2009, at 11:31 AM, Roger Binns wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Grzegorz Wierzchowski wrote: >> That was my first suspicion that there is some memmove with cursor >> object or so. >> This would mean that sqlite* or maybe other sensitive pointers can >> not be >> members of cursor object, what is wrong for me. > > There is an issue with mutexes and with using freed memory. > > My best guess as to what is going on is that you are freeing the db in > xClose and allocating in xFilter but that they end up mismatched in > some > way. You can see what has happened using valgrind. > > I compiled the testfixture like this: > > make -f Makefile.linux-gcc TOP=`pwd` BCC="gcc -g" TCC="gcc -g" > THREADLIB=-lpthread READLINE_FLAGS=-DHAVE_READLINE LIBREADLINE=- > lreadline > TCL_FLAGS=-I/usr/include/tcl8.4 LIBTCL=-ltcl testfixture > > valgrind then shows in detail what has happened. If you add > OPTS=-DSQLITE_DEBUG then you also get all SQLite assertions turned > on and a > mutex isn't held when it should be fires.
I don't think you can use sqlite3_result_value() with a value that comes from a different database connection. At least not currently. The xColumn() method of the patched echo-vtab does that. Dan. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users