Recompiled with: gcc -DSQLITE_THREADSAFE -I. -I../src -DSQLITE_DEBUG=1 -DTHREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -DHAVE_READLINE=1
Ran code (hardware is a dual core x86_64 amd cpu). sqlitetest_thrd35: ../src/btree.c:1816: sqlite3BtreeBeginTrans: Assertion `p->pBt->inTransaction>=p->inTrans' failed. Aborted Btree.c id: $Id: btree.c,v 1.420 2007/08/30 01:19:59 drh Exp $ [EMAIL PROTECTED] wrote: Joe Wilson wrote: > Compiled without -DSQLITE_DEBUG=1 which presumably changes the timing. > > cvs up -A > make distclean > # thrd35.c = http://marc.info/?l=sqlite-users&m=118848741522192&w=2 > cp thrd35.c src/shell.c > ../configure --disable-shared && make LIBPTHREAD=-lpthread sqlite3 > ../sqlite3 > valgrind -v ./sqlite3 2>&1 | tee v.log > I can reproduce this problem only when I compile with -DSQLITE_THREADSAFE=0. In other words, if I disable the mutexes completely, so that no mutex is ever called (the mutexing routines are all no-ops) then I can reproduce the problem. Amazingly enough, the test program works OK most of the time even with mutexes all disabled. But every now and then I get the segfault. It's a weak thread-test that works OK must of the time with mutexes disabled. :-) Or perhaps it is a very robust database engine ;-) Please recompile with -DSQLITE_THREADSAFE=1 and let me know if you are still having problems. I thought that SQLITE_THREADSAFE=1 was the default, but I could be mistaken. Are you using the configure script? -- D. Richard Hipp ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] ----------------------------------------------------------------------------- [EMAIL PROTECTED] wrote: Joe Wilson wrote: > Compiled without -DSQLITE_DEBUG=1 which presumably changes the timing. > > cvs up -A > make distclean > # thrd35.c = http://marc.info/?l=sqlite-users&m=118848741522192&w=2 > cp thrd35.c src/shell.c > ../configure --disable-shared && make LIBPTHREAD=-lpthread sqlite3 > ../sqlite3 > valgrind -v ./sqlite3 2>&1 | tee v.log > I can reproduce this problem only when I compile with -DSQLITE_THREADSAFE=0. In other words, if I disable the mutexes completely, so that no mutex is ever called (the mutexing routines are all no-ops) then I can reproduce the problem. Amazingly enough, the test program works OK most of the time even with mutexes all disabled. But every now and then I get the segfault. It's a weak thread-test that works OK must of the time with mutexes disabled. :-) Or perhaps it is a very robust database engine ;-) Please recompile with -DSQLITE_THREADSAFE=1 and let me know if you are still having problems. I thought that SQLITE_THREADSAFE=1 was the default, but I could be mistaken. Are you using the configure script? -- D. Richard Hipp ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
