Re: [sqlite] segmentation violation in fulltest on Mac OS X
Am 19.01.2009 um 18:42 schrieb D. Richard Hipp: > > On Jan 19, 2009, at 3:50 AM, Jens Miltner wrote: > >> Hello, >> >> I just upgraded to sqlite 3.6.10 and keep getting a segmentation >> violation when running the full tests on Mac OS X: >> The last test completed is consistently thread001.1.3. >> > > This was a problem in the testing logic, not in the SQLite library > itself. The test logic was trying to run a threading test with some > of the mutexes disabled. Everything works correctly once mutexes are > enabled properly. Thanks for the info - I applied the changes from checkin #6193 and the seg violations disappeared. However, I now get another bus error in perm-no_mutex_try.thread003.2 Do you need additional information? -jens ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] segmentation violation in fulltest on Mac OS X
> Of course, I wasted 4 hours tracking the problem down. This is > yet another episode that demonstrates how threads are a pernicious > evil that should be studiously avoided in any program that you > actually want to work. Threads cause hard-to-trace bugs. Threads > result in non-deterministic behavior. Threads make programs run > slower. Just say "No" to threads... Let me start by saying that I have a great respect for SQLite and its developers. I'm extremely pleased with the code itself as well as with the great support community. :) However, I'm a bit surprised by the "threads are evil" mantra. Certainly, threads can cause "hard-to-trace bugs" when used improperly. However the same can be said for many other language constructs, such as pointers, dynamic allocation, goto statements, etc. Any tool can get you into trouble if abused. No matter how you slice it, concurrent programing can be tricky. While multi-thread and multi-process approaches each have pros and cons, the dangers are the same: The programmer must take cautions to ensure that any shared resource is accessed safely. When used properly, either approach can work reliably. I have no doubt that there are many cases where the multi-process approach has clear benefits. Indeed, if one prefers the multi-process approach, then by all means use it. However, a multi-threaded approach can have benefits as well. Advocating a "one size fits all" approach for everyone, without knowing the details of a particular application, just seems an oversimplification to me. Sorry for my rant :) ~Eric ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] segmentation violation in fulltest on Mac OS X
Hello, Threads: use them, but don't abuse them Threads don't kill programs, programmers do ;-) Martin D. Richard Hipp wrote: > On Jan 19, 2009, at 3:50 AM, Jens Miltner wrote: > > >> Hello, >> >> I just upgraded to sqlite 3.6.10 and keep getting a segmentation >> violation when running the full tests on Mac OS X: >> The last test completed is consistently thread001.1.3. >> >> > > This was a problem in the testing logic, not in the SQLite library > itself. The test logic was trying to run a threading test with some > of the mutexes disabled. Everything works correctly once mutexes are > enabled properly. > > Of course, I wasted 4 hours tracking the problem down. This is > yet another episode that demonstrates how threads are a pernicious > evil that should be studiously avoided in any program that you > actually want to work. Threads cause hard-to-trace bugs. Threads > result in non-deterministic behavior. Threads make programs run > slower. Just say "No" to threads... > > D. Richard Hipp > d...@hwaci.com > > > > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] segmentation violation in fulltest on Mac OS X
"D. Richard Hipp" said, > slower. Just say "No" to threads... Can I quote you on that? :-) josé ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] segmentation violation in fulltest on Mac OS X
On Jan 19, 2009, at 3:50 AM, Jens Miltner wrote: > Hello, > > I just upgraded to sqlite 3.6.10 and keep getting a segmentation > violation when running the full tests on Mac OS X: > The last test completed is consistently thread001.1.3. > This was a problem in the testing logic, not in the SQLite library itself. The test logic was trying to run a threading test with some of the mutexes disabled. Everything works correctly once mutexes are enabled properly. Of course, I wasted 4 hours tracking the problem down. This is yet another episode that demonstrates how threads are a pernicious evil that should be studiously avoided in any program that you actually want to work. Threads cause hard-to-trace bugs. Threads result in non-deterministic behavior. Threads make programs run slower. Just say "No" to threads... D. Richard Hipp d...@hwaci.com ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] segmentation violation in fulltest on Mac OS X
Hello, I just upgraded to sqlite 3.6.10 and keep getting a segmentation violation when running the full tests on Mac OS X: The last test completed is consistently thread001.1.3. We're using a custom Xcode build of sqlite, so there's a chance that it has to do with our build settings. Unfortunately, I did not succeed in building the testfixture using the sqlite Makefile, so I can't really compare with the "official" build :( Anyway here's the build flags used to compile the source when building the testfixture in our custom project: /Developer/usr/bin/gcc-4.0 -x c -arch i386 -fmessage-length=0 -pipe - Wno-trigraphs -fpascal-strings -fasm-blocks -O2 -Wunused-label - DSQLITE_OS_UNIX=1 -DSQLITE_OMIT_CURSOR -DSQLITE_THREADSAFE=1 - DHAVE_USLEEP=1 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_TEMP_STORE=1 - DSQLITE_MAX_SQL_LENGTH=1 -DSQLITE_OMIT_MEMORY_ALLOCATION=1 - D__MACOS__=1 -DFD_SETSIZE=8192 -D_NONSTD_SOURCE=1 -DSQLITE_TEST=1 - DTCLSH=2 -DSQLITE_CRASH_TEST=1 -DSQLITE_SERVER=1 -DSQLITE_PRIVATE= - DSQLITE_CORE -DTEMP_STORE=1 -isysroot /Developer/SDKs/MacOSX10.5.sdk - fvisibility=hidden -mmacosx-version-min=10.4 -gdwarf-2 (FWIW, we're building everything using the amalgamation file.) Obviously, I'm a little concerned due to the crash in the test suite. If I'm missing some vital build settings here, I'd appreciate if someone could point this out to me. Has anybody else been running the test suite on Mac OS X? Are you seeing similar results or does it work for you? Any instructions on how to properly build the testfixture using the sqlite provided Makefile? Thanks, -jens ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
