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

Reply via email to