Re: [sqlite] version 3.5.0 - Segv
> In our tests, the overhead of mutexing is not negligible. It slows > down the > database by about 8%. Nevertheless, we recognize that many people want > to run multiple threads (despite my heartfelt pleas to abstain from > that dreadful > practice) so we probably will make the prebuilt libraries threadsafe > on all > platforms. I don't think 8% is a big deal considering the safety it offers a variety of programs when used as a shared library or the fewer false bug reports you'd receive if thread-safe was the default. Does anyone know if Mac OSX ships with a thread-safe sqlite3 system library? I'd be surprised if it were not. Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] version 3.5.0 - Segv
On Sep 2, 2007, at 10:18 AM, Christian Smith wrote: Is it not worth simply making the library threadsafe by default? There is basically no platform supported today that doesn't have some form of thread abstraction, the overhead of mutex locking is probably negligible, See ticket #2606. http://www.sqlite.org/cvstrac/tktview?tn=2606 In our tests, the overhead of mutexing is not negligible. It slows down the database by about 8%. Nevertheless, we recognize that many people want to run multiple threads (despite my heartfelt pleas to abstain from that dreadful practice) so we probably will make the prebuilt libraries threadsafe on all platforms. D. Richard Hipp [EMAIL PROTECTED] - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] version 3.5.0 - Segv
[EMAIL PROTECTED] uttered: [EMAIL PROTECTED] wrote: Ken <[EMAIL PROTECTED]> wrote: Recompiled with: gcc -DSQLITE_THREADSAFE -I. -I../src ^^^ Should be -DSQLITE_THREADSAFE=1 The =1 is important in this case. This problem will likely come up again. To try and work around it, I have added a new (experimental) API to the latest version in CVS. Call sqlite3_threadsafe() To get back a boolean to indicate whether or not your build is threadsafe. May I suggest adding a call to this routine at the beginning of sqlitetest_thrd35.c and printing and error message and aborting if the library is not threadsafe? Is it not worth simply making the library threadsafe by default? There is basically no platform supported today that doesn't have some form of thread abstraction, the overhead of mutex locking is probably negligible, and if someone wants an absolutely no holds barred fastest single threaded implementation, then they can provide their own platform abstraction with no-op mutexes. Christian -- /"\ \ /ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL X - AGAINST MS ATTACHMENTS / \ - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] version 3.5.0 - Segv
I did do an update this morning to pick up the latest code base. I guess the prior version that I had check out earlier in the week was not the most current. [EMAIL PROTECTED] wrote: Ken wrote: > The segv seems to be resolved. At least no more issues > with this version of the code. > That's funny, because I haven't changed anything to address your problem. I never could reproduce it. Perhaps you were using a version of the code that was two or three revs behind what I was using. There were many fixes to the multithreading logic earlier in the week. -- D. Richard Hipp - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] version 3.5.0 - Segv
--- Dan Kennedy <[EMAIL PROTECTED]> wrote: > On Thu, 2007-08-30 at 19:13 -0700, Joe Wilson wrote: > > I see what's going on now. I incorrectly assumed that both configure > > builds and the amalgamation were both threadsafe by default in the > > 3.4.x sources. > > > > It appears that a default ./configure without options for both 3.4.x > > and the new 3.5 sources will result in a non-threadsafe build. This > > has always been the case, since configure explicitly defines > > -DTHREADSAFE=0 in the Makefile. > > It's an ongoing problem that the configure script is a bit of > a second-class citizen. It's not convenient to develop with, > so people working on the sqlite code don't use it. Here's a patch to make configure default to a thread-safe build to match the default behavior of the amalgamation. http://www.sqlite.org/cvstrac/tktview?tn=2606 Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/ - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] version 3.5.0 - Segv
Ken <[EMAIL PROTECTED]> wrote: > The segv seems to be resolved. At least no more issues > with this version of the code. > That's funny, because I haven't changed anything to address your problem. I never could reproduce it. Perhaps you were using a version of the code that was two or three revs behind what I was using. There were many fixes to the multithreading logic earlier in the week. -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] version 3.5.0 - Segv
The segv seems to be resolved. At least no more issues with this version of the code. $Id: sqliteInt.h,v 1.606 2007/08/30 14:10:30 drh Exp $ Thanks for a great product. Ken
Re: [sqlite] version 3.5.0 - Segv
On Thu, 2007-08-30 at 19:13 -0700, Joe Wilson wrote: > > > > latest CVS: > > > > > > > > #if SQLITE_THREADSAFE > > > > # include > > > > # define SQLITE_UNIX_THREADS 1 > > > > #endif > > > > > > > > > > I don't know where you are seeing this. The latest is > > > > > > > > > http://www.sqlite.org/cvstrac/filediff?f=sqlite/src/sqliteInt.h=1.592=1.593 > > > > Look in sqlite 3.4.2 os_unix.c. > > > > http://www.sqlite.org/cvstrac/fileview?f=sqlite/src/os_unix.c=1.136 > > > > Before 3.5 it was the only sqlite source file where thread-safety was > > relevant > > for UNIX. > > I see what's going on now. I incorrectly assumed that both configure > builds and the amalgamation were both threadsafe by default in the > 3.4.x sources. > > It appears that a default ./configure without options for both 3.4.x > and the new 3.5 sources will result in a non-threadsafe build. This > has always been the case, since configure explicitly defines > -DTHREADSAFE=0 in the Makefile. It's an ongoing problem that the configure script is a bit of a second-class citizen. It's not convenient to develop with, so people working on the sqlite code don't use it. Dan. - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] version 3.5.0 - Segv
> > > latest CVS: > > > > > > #if SQLITE_THREADSAFE > > > # include > > > # define SQLITE_UNIX_THREADS 1 > > > #endif > > > > > > > I don't know where you are seeing this. The latest is > > > > > > http://www.sqlite.org/cvstrac/filediff?f=sqlite/src/sqliteInt.h=1.592=1.593 > > Look in sqlite 3.4.2 os_unix.c. > > http://www.sqlite.org/cvstrac/fileview?f=sqlite/src/os_unix.c=1.136 > > Before 3.5 it was the only sqlite source file where thread-safety was relevant > for UNIX. I see what's going on now. I incorrectly assumed that both configure builds and the amalgamation were both threadsafe by default in the 3.4.x sources. It appears that a default ./configure without options for both 3.4.x and the new 3.5 sources will result in a non-threadsafe build. This has always been the case, since configure explicitly defines -DTHREADSAFE=0 in the Makefile. The sqlite3.c amalgamation, on the other hand, with no compile flags does result in a threadsafe build for both 3.4.x and 3.5. So the "threadsafe by default" cvs log comment in os_unix.c has to be taken in context. Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] version 3.5.0 - Segv
--- [EMAIL PROTECTED] wrote: > This problem will likely come up again. To try and work > around it, I have added a new (experimental) API to the > latest version in CVS. Call > > sqlite3_threadsafe() > > To get back a boolean to indicate whether or not your > build is threadsafe. Could you also make an accompanying SQLite SQL function of the same name? Many SQLite wrapper users (Java, PHP, whatever) have no knowledge of C or how their drivers are built and it would be useful for diagnosing problems via SQL only. Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail=summer+activities+for+kids=bz - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] version 3.5.0 - Segv
--- [EMAIL PROTECTED] wrote:
> Ken <[EMAIL PROTECTED]> wrote:
> > Recompiled with:
> > gcc -DSQLITE_THREADSAFE -I. -I../src
> ^^^
>
> Should be -DSQLITE_THREADSAFE=1
>
> The =1 is important in this case.
-DSQLITE_THREADSAFE is equivalent to -DSQLITE_THREADSAFE=1
$ cat t.c
#include
main() { printf("SQLITE_THREADSAFE = %d\n", SQLITE_THREADSAFE); }
$ gcc -DSQLITE_THREADSAFE t.c
$ ./a.out
SQLITE_THREADSAFE = 1
$ gcc -DSQLITE_THREADSAFE=0 t.c
$ ./a.out
SQLITE_THREADSAFE = 0
Be a better Globetrotter. Get better travel answers from someone who knows.
Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list=396545469
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
Re: [sqlite] version 3.5.0 - Segv
[EMAIL PROTECTED] wrote: > Ken <[EMAIL PROTECTED]> wrote: > > Recompiled with: > > gcc -DSQLITE_THREADSAFE -I. -I../src > ^^^ > > Should be -DSQLITE_THREADSAFE=1 > > The =1 is important in this case. > This problem will likely come up again. To try and work around it, I have added a new (experimental) API to the latest version in CVS. Call sqlite3_threadsafe() To get back a boolean to indicate whether or not your build is threadsafe. May I suggest adding a call to this routine at the beginning of sqlitetest_thrd35.c and printing and error message and aborting if the library is not threadsafe? -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] version 3.5.0 - Segv
Ken <[EMAIL PROTECTED]> wrote: > Recompiled with: > gcc -DSQLITE_THREADSAFE -I. -I../src ^^^ Should be -DSQLITE_THREADSAFE=1 The =1 is important in this case. -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] version 3.5.0 - Segv
And the sqliteInt.h file is id as: ** @(#) $Id: sqliteInt.h,v 1.605 2007/08/29 12:31:28 danielk1977 Exp $ Let me know if you need anything else.. Thanks, Ken [EMAIL PROTECTED] wrote: Joe Wilson wrote: > > latest CVS: > > #if SQLITE_THREADSAFE > # include > # define SQLITE_UNIX_THREADS 1 > #endif > I don't know where you are seeing this. The latest is http://www.sqlite.org/cvstrac/filediff?f=sqlite/src/sqliteInt.h=1.592=1.593 -- D. Richard Hipp - To unsubscribe, send email to [EMAIL PROTECTED] - [EMAIL PROTECTED] wrote: Joe Wilson wrote: > > latest CVS: > > #if SQLITE_THREADSAFE > # include > # define SQLITE_UNIX_THREADS 1 > #endif > I don't know where you are seeing this. The latest is http://www.sqlite.org/cvstrac/filediff?f=sqlite/src/sqliteInt.h=1.592=1.593 -- D. Richard Hipp - To unsubscribe, send email to [EMAIL PROTECTED] - [EMAIL PROTECTED] wrote: Joe Wilson wrote: > > latest CVS: > > #if SQLITE_THREADSAFE > # include > # define SQLITE_UNIX_THREADS 1 > #endif > I don't know where you are seeing this. The latest is http://www.sqlite.org/cvstrac/filediff?f=sqlite/src/sqliteInt.h=1.592=1.593 -- D. Richard Hipp - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] version 3.5.0 - Segv
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=118848741522192=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=118848741522192=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] -
Re: [sqlite] version 3.5.0 - Segv
** $Id: btree.c,v 1.420 2007/08/30 01:19:59 drh Exp $ Compilation: ../configure --enable-threadsafe --disable-tcl --enable-tempstore make gcc -g -O2 -I. -I../src -DNDEBUG -DTHREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -c ../src/alter.c -o alter.o >/dev/null 2>&1 --So this is a configure or makefile issue? Since DTHREADSAFE should be SQLITE_THREADSAFE ... I'll set the CFLAGS to set up SQLITE_THREADSAFE [EMAIL PROTECTED] wrote: Joe Wilson wrote: > I also see random crashes with sources from CVS as of > Thu Aug 30 12:20:43 EDT 2007 using Ken's program below. > > http://marc.info/?l=sqlite-users=118848741522192=2 > > It's timing dependent. > On a single core Pentium4 machine it crashes once in 10 runs. > Compiled with or without -DSQLITE_DEBUG=1? We have a bazillion assert()s in place that are suppose to catch this kind of thing. I'm wondering if the problem slipped through, or if you have the assert()s turned off. (Assert()s in SQLite are off by default. You have to turn them on explicitly using -DSQLITE_DEBUG=1.) -- D. Richard Hipp - To unsubscribe, send email to [EMAIL PROTECTED] - [EMAIL PROTECTED] wrote: Joe Wilson wrote: > I also see random crashes with sources from CVS as of > Thu Aug 30 12:20:43 EDT 2007 using Ken's program below. > > http://marc.info/?l=sqlite-users=118848741522192=2 > > It's timing dependent. > On a single core Pentium4 machine it crashes once in 10 runs. > Compiled with or without -DSQLITE_DEBUG=1? We have a bazillion assert()s in place that are suppose to catch this kind of thing. I'm wondering if the problem slipped through, or if you have the assert()s turned off. (Assert()s in SQLite are off by default. You have to turn them on explicitly using -DSQLITE_DEBUG=1.) -- D. Richard Hipp - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] version 3.5.0 - Segv
--- [EMAIL PROTECTED] wrote: > 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 ;-) Uniprocessors, like the machine I was using, are notoriously bad test platforms for multi-threaded code. You really need SMP machines to thoroughly exercise multi-threaded logic. The more cores the better. Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list=396545433 - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] version 3.5.0 - Segv
--- [EMAIL PROTECTED] wrote: > Joe Wilson <[EMAIL PROTECTED]> wrote: > > > > latest CVS: > > > > #if SQLITE_THREADSAFE > > # include > > # define SQLITE_UNIX_THREADS 1 > > #endif > > > > I don't know where you are seeing this. The latest is > > > http://www.sqlite.org/cvstrac/filediff?f=sqlite/src/sqliteInt.h=1.592=1.593 Look in sqlite 3.4.2 os_unix.c. http://www.sqlite.org/cvstrac/fileview?f=sqlite/src/os_unix.c=1.136 Before 3.5 it was the only sqlite source file where thread-safety was relevant for UNIX. sqlite-3.4.1$ grep -nl THREADS src/*.c src/os_os2.c src/os_unix.c src/os_win.c src/test1.c src/test4.c src/test7.c src/test_async.c src/test_config.c src/test_server.c Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] version 3.5.0 - Segv
Joe Wilson <[EMAIL PROTECTED]> wrote: > > latest CVS: > > #if SQLITE_THREADSAFE > # include > # define SQLITE_UNIX_THREADS 1 > #endif > I don't know where you are seeing this. The latest is http://www.sqlite.org/cvstrac/filediff?f=sqlite/src/sqliteInt.h=1.592=1.593 -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] version 3.5.0 - Segv
--- Joe Wilson <[EMAIL PROTECTED]> wrote: > I thought there was a checkin a few months ago that made sqlite3 > threadsafe by default. > > os_unix.c > revision 1.128 > date: 2007/04/01 18:46:19; author: drh; state: Exp; lines: +4 -1 > Make unix builds threadsafe by default. > > I guess this is no longer the case? Okay, it appears that this is new to 3.5. THREADSAFE is no longer the default since thread safety is no longer confined to just os_unix.c. sqlite 3.4.1: #ifndef THREADSAFE # define THREADSAFE 1 #endif #if THREADSAFE # include # define SQLITE_UNIX_THREADS 1 #endif latest CVS: #if SQLITE_THREADSAFE # include # define SQLITE_UNIX_THREADS 1 #endif Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] version 3.5.0 - Segv
--- Dan Kennedy <[EMAIL PROTECTED]> wrote: > On Thu, 2007-08-30 at 10:13 -0700, 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=118848741522192=2 > > cp thrd35.c src/shell.c > > ./configure --disable-shared && make LIBPTHREAD=-lpthread sqlite3 > > ./sqlite3 > > valgrind -v ./sqlite3 2>&1 | tee v.log > > Try adding --enable-threadsafe to the configure command. Does the > valgrind log look any better after doing so? That explains it. I'm surprised I missed that. I thought there was a checkin a few months ago that made sqlite3 threadsafe by default. os_unix.c revision 1.128 date: 2007/04/01 18:46:19; author: drh; state: Exp; lines: +4 -1 Make unix builds threadsafe by default. I guess this is no longer the case? Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list=396545469 - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] version 3.5.0 - Segv
Joe Wilson <[EMAIL PROTECTED]> wrote: > Compiled without -DSQLITE_DEBUG=1 which presumably changes the timing. > > cvs up -A > make distclean > # thrd35.c = http://marc.info/?l=sqlite-users=118848741522192=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 <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] version 3.5.0 - Segv
On Thu, 2007-08-30 at 10:13 -0700, 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=118848741522192=2 > cp thrd35.c src/shell.c > ./configure --disable-shared && make LIBPTHREAD=-lpthread sqlite3 > ./sqlite3 > valgrind -v ./sqlite3 2>&1 | tee v.log Try adding --enable-threadsafe to the configure command. Does the valgrind log look any better after doing so? Dan. > > --- [EMAIL PROTECTED] wrote: > > Compiled with or without -DSQLITE_DEBUG=1? We have a bazillion > > assert()s in place that are suppose to catch this kind of thing. > > > > > > > Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel > and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 > > > - > To unsubscribe, send email to [EMAIL PROTECTED] > - > - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] version 3.5.0 - Segv
Compiled without -DSQLITE_DEBUG=1 which presumably changes the timing. cvs up -A make distclean # thrd35.c = http://marc.info/?l=sqlite-users=118848741522192=2 cp thrd35.c src/shell.c ./configure --disable-shared && make LIBPTHREAD=-lpthread sqlite3 ./sqlite3 valgrind -v ./sqlite3 2>&1 | tee v.log --- [EMAIL PROTECTED] wrote: > Compiled with or without -DSQLITE_DEBUG=1? We have a bazillion > assert()s in place that are suppose to catch this kind of thing. Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] version 3.5.0 - Segv
Joe Wilson <[EMAIL PROTECTED]> wrote: > I also see random crashes with sources from CVS as of > Thu Aug 30 12:20:43 EDT 2007 using Ken's program below. > > http://marc.info/?l=sqlite-users=118848741522192=2 > > It's timing dependent. > On a single core Pentium4 machine it crashes once in 10 runs. > Compiled with or without -DSQLITE_DEBUG=1? We have a bazillion assert()s in place that are suppose to catch this kind of thing. I'm wondering if the problem slipped through, or if you have the assert()s turned off. (Assert()s in SQLite are off by default. You have to turn them on explicitly using -DSQLITE_DEBUG=1.) -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] version 3.5.0 - Segv
Another unique valgrind stack trace. http://marc.info/?l=sqlite-users=118848741522192=2 ==14918== Thread 2: ==14918== Invalid read of size 4 ==14918==at 0x80534F9: sqlite3OsWrite (os.c:38) ==14918==by 0x8056C06: syncJournal (pager.c:2765) ==14918==by 0x80581A8: sqlite3PagerCommitPhaseOne (pager.c:4461) ==14918==by 0x8050731: sqlite3BtreeCommitPhaseOne (btree.c:2315) ==14918==by 0x805DBC2: sqlite3VdbeHalt (vdbeaux.c:1131) ==14918==by 0x80815E6: sqlite3VdbeExec (vdbe.c:2465) ==14918==by 0x805C209: sqlite3_step (vdbeapi.c:328) ==14918==by 0x8060951: sqlite3_exec (legacy.c:77) ==14918==by 0x8048FD9: sqlite3_execute (thrd35.c:122) ==14918==by 0x80495DD: testthread (thrd35.c:261) ==14918==by 0x403A561: start_thread (in /lib/i686/libpthread-2.4.so) ==14918==by 0x418D4DD: clone (in /lib/i686/libc-2.4.so) ==14918== Address 0xC is not stack'd, malloc'd or (recently) free'd ==14918== ==14918== Process terminating with default action of signal 11 (SIGSEGV) ==14918== Access not within mapped region at address 0xC ==14918==at 0x80534F9: sqlite3OsWrite (os.c:38) ==14918==by 0x8056C06: syncJournal (pager.c:2765) ==14918==by 0x80581A8: sqlite3PagerCommitPhaseOne (pager.c:4461) ==14918==by 0x8050731: sqlite3BtreeCommitPhaseOne (btree.c:2315) ==14918==by 0x805DBC2: sqlite3VdbeHalt (vdbeaux.c:1131) ==14918==by 0x80815E6: sqlite3VdbeExec (vdbe.c:2465) ==14918==by 0x805C209: sqlite3_step (vdbeapi.c:328) ==14918==by 0x8060951: sqlite3_exec (legacy.c:77) ==14918==by 0x8048FD9: sqlite3_execute (thrd35.c:122) ==14918==by 0x80495DD: testthread (thrd35.c:261) ==14918==by 0x403A561: start_thread (in /lib/i686/libpthread-2.4.so) ==14918==by 0x418D4DD: clone (in /lib/i686/libc-2.4.so) t count(*) from test_Table Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/ - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] version 3.5.0 - Segv
Also: ==14673== Invalid read of size 4 ==14673==at 0x80534F9: sqlite3OsWrite (os.c:38) ==14673==by 0x8050A17: sqlite3BtreeBeginTrans (btree.c:1850) ==14673==by 0x807E068: sqlite3VdbeExec (vdbe.c:2519) ==14673==by 0x805C209: sqlite3_step (vdbeapi.c:328) ==14673==by 0x8060951: sqlite3_exec (legacy.c:77) ==14673==by 0x8048FD9: sqlite3_execute (thrd35.c:122) ==14673==by 0x8049566: testthread (thrd35.c:240) ==14673==by 0x403A561: start_thread (in /lib/i686/libpthread-2.4.so) ==14673==by 0x418D4DD: clone (in /lib/i686/libc-2.4.so) ==14673== Address 0xC is not stack'd, malloc'd or (recently) free'd ==14673== ==14673== Process terminating with default action of signal 11 (SIGSEGV) ==14673== Access not within mapped region at address 0xC ==14673==at 0x80534F9: sqlite3OsWrite (os.c:38) ==14673==by 0x8050A17: sqlite3BtreeBeginTrans (btree.c:1850) ==14673==by 0x807E068: sqlite3VdbeExec (vdbe.c:2519) ==14673==by 0x805C209: sqlite3_step (vdbeapi.c:328) ==14673==by 0x8060951: sqlite3_exec (legacy.c:77) ==14673==by 0x8048FD9: sqlite3_execute (thrd35.c:122) ==14673==by 0x8049566: testthread (thrd35.c:240) ==14673==by 0x403A561: start_thread (in /lib/i686/libpthread-2.4.so) ==14673==by 0x418D4DD: clone (in /lib/i686/libc-2.4.so) ==14673==by 0xA: ??? ==14673==by 0x38134192: (within /usr/lib/valgrind/x86-linux/memcheck) ==14673==by 0x2: ??? --- Joe Wilson <[EMAIL PROTECTED]> wrote: > I also see random crashes with sources from CVS as of > Thu Aug 30 12:20:43 EDT 2007 using Ken's program below. > > http://marc.info/?l=sqlite-users=118848741522192=2 > > It's timing dependent. > On a single core Pentium4 machine it crashes once in 10 runs. > > Sometimes it produces this valgrind error: > > ==14637== Thread 4: > ==14637== Invalid read of size 4 > ==14637==at 0x804D951: balance_nonroot (btree.c:4774) > ==14637==by 0x804E840: balance (btree.c:5469) > ==14637==by 0x805013B: sqlite3BtreeInsert (btree.c:5601) > ==14637==by 0x807EAC1: sqlite3VdbeExec (vdbe.c:3506) > ==14637==by 0x805C209: sqlite3_step (vdbeapi.c:328) > ==14637==by 0x8060951: sqlite3_exec (legacy.c:77) > ==14637==by 0x8048FD9: sqlite3_execute (thrd35.c:122) > ==14637==by 0x80495B7: testthread (thrd35.c:251) > ==14637==by 0x403A561: start_thread (in /lib/i686/libpthread-2.4.so) > ==14637==by 0x418D4DD: clone (in /lib/i686/libc-2.4.so) > ==14637== Address 0x4C is not stack'd, malloc'd or (recently) free'd > ==14637== > ==14637== Process terminating with default action of signal 11 (SIGSEGV) > ==14637== Access not within mapped region at address 0x4C > ==14637==at 0x804D951: balance_nonroot (btree.c:4774) > ==14637==by 0x804E840: balance (btree.c:5469) > ==14637==by 0x805013B: sqlite3BtreeInsert (btree.c:5601) > ==14637==by 0x807EAC1: sqlite3VdbeExec (vdbe.c:3506) > ==14637==by 0x805C209: sqlite3_step (vdbeapi.c:328) > ==14637==by 0x8060951: sqlite3_exec (legacy.c:77) > ==14637==by 0x8048FD9: sqlite3_execute (thrd35.c:122) > ==14637==by 0x80495B7: testthread (thrd35.c:251) > ==14637==by 0x403A561: start_thread (in /lib/i686/libpthread-2.4.so) > ==14637==by 0x418D4DD: clone (in /lib/i686/libc-2.4.so) > ==14637==by 0x38134192: (within /usr/lib/valgrind/x86-linux/memcheck) > ==14637==by 0x3: ??? Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/ - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] version 3.5.0 - Segv
I also see random crashes with sources from CVS as of Thu Aug 30 12:20:43 EDT 2007 using Ken's program below. http://marc.info/?l=sqlite-users=118848741522192=2 It's timing dependent. On a single core Pentium4 machine it crashes once in 10 runs. Sometimes it produces this valgrind error: ==14637== Thread 4: ==14637== Invalid read of size 4 ==14637==at 0x804D951: balance_nonroot (btree.c:4774) ==14637==by 0x804E840: balance (btree.c:5469) ==14637==by 0x805013B: sqlite3BtreeInsert (btree.c:5601) ==14637==by 0x807EAC1: sqlite3VdbeExec (vdbe.c:3506) ==14637==by 0x805C209: sqlite3_step (vdbeapi.c:328) ==14637==by 0x8060951: sqlite3_exec (legacy.c:77) ==14637==by 0x8048FD9: sqlite3_execute (thrd35.c:122) ==14637==by 0x80495B7: testthread (thrd35.c:251) ==14637==by 0x403A561: start_thread (in /lib/i686/libpthread-2.4.so) ==14637==by 0x418D4DD: clone (in /lib/i686/libc-2.4.so) ==14637== Address 0x4C is not stack'd, malloc'd or (recently) free'd ==14637== ==14637== Process terminating with default action of signal 11 (SIGSEGV) ==14637== Access not within mapped region at address 0x4C ==14637==at 0x804D951: balance_nonroot (btree.c:4774) ==14637==by 0x804E840: balance (btree.c:5469) ==14637==by 0x805013B: sqlite3BtreeInsert (btree.c:5601) ==14637==by 0x807EAC1: sqlite3VdbeExec (vdbe.c:3506) ==14637==by 0x805C209: sqlite3_step (vdbeapi.c:328) ==14637==by 0x8060951: sqlite3_exec (legacy.c:77) ==14637==by 0x8048FD9: sqlite3_execute (thrd35.c:122) ==14637==by 0x80495B7: testthread (thrd35.c:251) ==14637==by 0x403A561: start_thread (in /lib/i686/libpthread-2.4.so) ==14637==by 0x418D4DD: clone (in /lib/i686/libc-2.4.so) ==14637==by 0x38134192: (within /usr/lib/valgrind/x86-linux/memcheck) ==14637==by 0x3: ??? --- [EMAIL PROTECTED] wrote: > Ken <[EMAIL PROTECTED]> wrote: > > program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 1080043872 (LWP 15448)] > > moveToChild (pCur=0x569058, newPgno=) at btree.c:3304 > > (gdb) > > > > > > if( rc ) return rc; > > pNewPage->idxParent = pCur->idx; > > pOldPage = pCur->pPage; > > pOldPage->idxShift = 0; < Error Here > > releasePage(pOldPage); > > pCur->pPage = pNewPage; > > pCur->idx = 0; > > pCur->info.nSize = 0; > > > > When did you check-out the sources? There have been a lot > of changes lately. What is the RCS version number on your > btree.c source file (in the header comment at the top)? Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail=summer+activities+for+kids=bz - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] version 3.5.0 - Segv
Ken <[EMAIL PROTECTED]> wrote: > program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 1080043872 (LWP 15448)] > moveToChild (pCur=0x569058, newPgno=) at btree.c:3304 > (gdb) > > > if( rc ) return rc; > pNewPage->idxParent = pCur->idx; > pOldPage = pCur->pPage; > pOldPage->idxShift = 0; < Error Here > releasePage(pOldPage); > pCur->pPage = pNewPage; > pCur->idx = 0; > pCur->info.nSize = 0; > When did you check-out the sources? There have been a lot of changes lately. What is the RCS version number on your btree.c source file (in the header comment at the top)? -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] version 3.5.0 - Segv
Dan Source code is attached. I didn't write this, someone else from the forum
did their name is not on it, nor coppyrighted.. I thought it was a clean way to
test threading.
Interestingly if you remove out the shared cache everything runs to completion.
Dan Kennedy <[EMAIL PROTECTED]> wrote:
Hi Ken,
Probably a bug in the new threading stuff. Can you share
source code for this test or is it part of some large app?
Either way, thanks for the report.
Dan.
On Wed, 2007-08-29 at 22:15 -0700, Ken wrote:
> Also erros out here, sporadically.
> int sqlite3OsWrite(sqlite3_file *id, const void *pBuf, int amt, i64 offset){
> return id->pMethods->xWrite(id, pBuf, amt, offset);
> }
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1075841376 (LWP 15747)]
> 0x0040c413 in sqlite3OsWrite (id=0x55aaa0, pBuf=0x401ffc30, amt=24,
> offset=0) at os.c:38
> (gdb) Quit
> (gdb)
>
> Ken wrote: 4 threads, shared_Cache enabled
> LOOP 100
> BEGIN
> LOOP 50 times
> INSERT
> end LOOP
> COMMIT
>
> SELECT COUNT(*) ...
> end LOOP
>
>
> program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1080043872 (LWP 15448)]
> moveToChild (pCur=0x569058, newPgno=) at btree.c:3304
> (gdb)
>
>
> if( rc ) return rc;
> pNewPage->idxParent = pCur->idx;
> pOldPage = pCur->pPage;
> pOldPage->idxShift = 0; < Error Here
> releasePage(pOldPage);
> pCur->pPage = pNewPage;
> pCur->idx = 0;
> pCur->info.nSize = 0;
>
>
> Ken
>
>
>
>
> Ken wrote: 4 threads, shared_Cache enabled
> LOOP 100
> BEGIN
> LOOP 50 times
> INSERT
> end LOOP
> COMMIT
>
> SELECT COUNT(*) ...
> end LOOP
>
>
> program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1080043872 (LWP 15448)]
> moveToChild (pCur=0x569058, newPgno=) at btree.c:3304
> (gdb)
>
>
> if( rc ) return rc;
> pNewPage->idxParent = pCur->idx;
> pOldPage = pCur->pPage;
> pOldPage->idxShift = 0; < Error Here
> releasePage(pOldPage);
> pCur->pPage = pNewPage;
> pCur->idx = 0;
> pCur->info.nSize = 0;
>
>
> Ken
>
>
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
#include
#include
#include
#include
#include
#include
#ifdef __Linux__
# define _XOPEN_SOURCE 500
#endif
#include
#define SQLITEDB "test.db"
#define NUM_THREADS 4
#define MAX_BUSY 25
#define NUM_LOOPS 200
#define NUM_INSERTS 10
#define SHARED_CACHE 1
#ifndef RETRY_BUSY
#define RETRY_BUSY 1
#endif
static void sync_thread(int thnum);
typedef struct sql_result {
int alloc_rows;
int rows;
int cols;
char ***data;
} sql_result;
typedef struct th_st {
int th_num;
/* 0 = not started, 1 = started, 2 = done, 3 = error */
int state;
} th_st;
th_st *th_data = NULL;
pthread_mutex_t global_mutex;
int on_thread = 0;
#define SQLITE_ALLOC_ROWS 1024
static int sqlite3_rowcallback(void *myresult, int argc, char **argv, char **colName)
{
sql_result *result = myresult;
int i;
(void)colName;
if (result == NULL)
return (SQLITE_ERROR);
if (result->cols == 0)
result->cols=argc;
else if (result->cols != argc)
return (SQLITE_ERROR);
if (result->rows >= result->alloc_rows) {
result->data=(char ***)realloc(result->data, (result->alloc_rows+SQLITE_ALLOC_ROWS)*sizeof(char **));
result->alloc_rows += SQLITE_ALLOC_ROWS;
}
result->data[result->rows] = (char **)malloc((result->cols)*sizeof(char *));
for (i=0; icols; i++) {
if (argv[i] == NULL)
result->data[result->rows][i] = NULL;
else
result->data[result->rows][i] = strdup(argv[i]);
}
result->rows++;
return(SQLITE_OK);
}
static void sqlite3_printresult(sql_result *result)
{
int i, j;
if (!result->rows) return;
printf("Query Results:\n");
for (i=0; irows; i++) {
for (j=0; jcols; j++) {
if (j != 0)
printf(",");
printf("%s", result->data[i][j]);
}
printf("\n");
}
printf("\n");
}
static void sqlite3_freeresult(sql_result *result)
{
int i, j;
if (!result->rows) return;
for (i=0; irows; i++) {
for (j=0; jcols; j++) {
free(result->data[i][j]);
}
free(result->data[i]);
}
free(result->data);
}
/** sqlite3_execute
* Description: Execute SQL statment, loop on busy
* Return : 1 on success, 0 on failure, -1 on rollback/concurrency issue
*/
static int sqlite3_execute(sqlite3 *db_conn, const char *statement, int thnum)
{
int rc, retval;
sql_result result;
char *errmsg = NULL;
#if RETRY_BUSY
int busy_cnt = 0;
#endif
memset(, 0, sizeof(result));
do {
errmsg = NULL;
printf("%d => Executing: %s\n", thnum, statement);
rc = sqlite3_exec(db_conn, statement, sqlite3_rowcallback, , );
switch (rc) {
case SQLITE_OK:
retval = 1;
break;
case SQLITE_BUSY:
#if RETRY_BUSY
busy_cnt++;
break;
#endif
case SQLITE_LOCKED:
/* Issue a
Re: [sqlite] version 3.5.0 - Segv
Hi Ken,
Probably a bug in the new threading stuff. Can you share
source code for this test or is it part of some large app?
Either way, thanks for the report.
Dan.
On Wed, 2007-08-29 at 22:15 -0700, Ken wrote:
> Also erros out here, sporadically.
> int sqlite3OsWrite(sqlite3_file *id, const void *pBuf, int amt, i64 offset){
> return id->pMethods->xWrite(id, pBuf, amt, offset);
> }
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1075841376 (LWP 15747)]
> 0x0040c413 in sqlite3OsWrite (id=0x55aaa0, pBuf=0x401ffc30, amt=24,
> offset=0) at os.c:38
> (gdb) Quit
> (gdb)
>
> Ken <[EMAIL PROTECTED]> wrote: 4 threads, shared_Cache enabled
> LOOP 100
> BEGIN
> LOOP 50 times
> INSERT
> end LOOP
> COMMIT
>
> SELECT COUNT(*) ...
> end LOOP
>
>
> program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1080043872 (LWP 15448)]
> moveToChild (pCur=0x569058, newPgno=) at btree.c:3304
> (gdb)
>
>
> if( rc ) return rc;
> pNewPage->idxParent = pCur->idx;
> pOldPage = pCur->pPage;
> pOldPage->idxShift = 0; < Error Here
> releasePage(pOldPage);
> pCur->pPage = pNewPage;
> pCur->idx = 0;
> pCur->info.nSize = 0;
>
>
> Ken
>
>
>
>
> Ken <[EMAIL PROTECTED]> wrote: 4 threads, shared_Cache enabled
> LOOP 100
> BEGIN
> LOOP 50 times
> INSERT
> end LOOP
> COMMIT
>
> SELECT COUNT(*) ...
> end LOOP
>
>
> program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1080043872 (LWP 15448)]
> moveToChild (pCur=0x569058, newPgno=) at btree.c:3304
> (gdb)
>
>
> if( rc ) return rc;
> pNewPage->idxParent = pCur->idx;
> pOldPage = pCur->pPage;
> pOldPage->idxShift = 0; < Error Here
> releasePage(pOldPage);
> pCur->pPage = pNewPage;
> pCur->idx = 0;
> pCur->info.nSize = 0;
>
>
> Ken
>
>
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
Re: [sqlite] version 3.5.0 - Segv
Also erros out here, sporadically.
int sqlite3OsWrite(sqlite3_file *id, const void *pBuf, int amt, i64 offset){
return id->pMethods->xWrite(id, pBuf, amt, offset);
}
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1075841376 (LWP 15747)]
0x0040c413 in sqlite3OsWrite (id=0x55aaa0, pBuf=0x401ffc30, amt=24,
offset=0) at os.c:38
(gdb) Quit
(gdb)
Ken <[EMAIL PROTECTED]> wrote: 4 threads, shared_Cache enabled
LOOP 100
BEGIN
LOOP 50 times
INSERT
end LOOP
COMMIT
SELECT COUNT(*) ...
end LOOP
program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1080043872 (LWP 15448)]
moveToChild (pCur=0x569058, newPgno=) at btree.c:3304
(gdb)
if( rc ) return rc;
pNewPage->idxParent = pCur->idx;
pOldPage = pCur->pPage;
pOldPage->idxShift = 0; < Error Here
releasePage(pOldPage);
pCur->pPage = pNewPage;
pCur->idx = 0;
pCur->info.nSize = 0;
Ken
Ken <[EMAIL PROTECTED]> wrote: 4 threads, shared_Cache enabled
LOOP 100
BEGIN
LOOP 50 times
INSERT
end LOOP
COMMIT
SELECT COUNT(*) ...
end LOOP
program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1080043872 (LWP 15448)]
moveToChild (pCur=0x569058, newPgno=) at btree.c:3304
(gdb)
if( rc ) return rc;
pNewPage->idxParent = pCur->idx;
pOldPage = pCur->pPage;
pOldPage->idxShift = 0; < Error Here
releasePage(pOldPage);
pCur->pPage = pNewPage;
pCur->idx = 0;
pCur->info.nSize = 0;
Ken
[sqlite] version 3.5.0 - Segv
4 threads, shared_Cache enabled LOOP 100 BEGIN LOOP 50 times INSERT end LOOP COMMIT SELECT COUNT(*) ... end LOOP program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1080043872 (LWP 15448)] moveToChild (pCur=0x569058, newPgno=) at btree.c:3304 (gdb) if( rc ) return rc; pNewPage->idxParent = pCur->idx; pOldPage = pCur->pPage; pOldPage->idxShift = 0; < Error Here releasePage(pOldPage); pCur->pPage = pNewPage; pCur->idx = 0; pCur->info.nSize = 0; Ken
[sqlite] version 3.5.0 - Segv
program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1080043872 (LWP 15448)] moveToChild (pCur=0x569058, newPgno=) at btree.c:3304 (gdb) if( rc ) return rc; pNewPage->idxParent = pCur->idx; pOldPage = pCur->pPage; pOldPage->idxShift = 0; < Error Here releasePage(pOldPage); pCur->pPage = pNewPage; pCur->idx = 0; pCur->info.nSize = 0; Ken
