[sqlite] Compiling on SCO OSR5
Hello:
I have compiled sqlite3.2.5 on OSR5 using gcc 2.95 and run the
fulltest set.
This results in a large number of failures of the crash tests all of
which have the following format
crash-4.2.1036.1...
Expected: [1 {child process exited abnormally}]
Got: [1 /wk/BUILD/bld/.libs/lt-crashtest:\ disk\ I/O\
error\n\ \ \
\ while\ executing\n\"db\ eval\ \{\n\n\
\ \ \ \ \ \ ATTACH\ 'test2.db'\ AS\ aux\;\n\ \ \ \ \ \ \
BEGIN\;\n\ \ \
\ \ \ \ SELECT\ random()\ FROM\ abc\ LIM
IT\ 1036\;\n\ \ \ \ \ \ \ INSERT\ INTO\ abc\ VALUES(randstr(10,10),\
0,...\"\n\ \ \ \ (file\ \"crash.tcl\"\ line
\ 6)]
crash-4.2.1036.2... Ok
crash-4.2.1036.3... Ok
I have 2 questions -
1. Should I be worried about these failures?
2. Any suggestions as to how to make the tests pass?
Thanks, Nigel Ball
RE: [sqlite] DETACHing database after sqlite3_step, but before sqlite3_finalize causes crash in btree.c
Yea, but it should have returned an error code or something, not an access violation. -Original Message- From: Jay Sprenkle [mailto:[EMAIL PROTECTED] Sent: Friday, September 02, 2005 9:54 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] DETACHing database after sqlite3_step, but before sqlite3_finalize causes crash in btree.c On 9/1/05, Damian Slee <[EMAIL PROTECTED]> wrote: > > > Work arounds are to call sqlite3_finalize on the query (to cleanup) > before detaching, or only selecting the top N in the first place. > > I don't know the internals well enough to fix it myself.. Sounds like you found your answers already ;) --- The Castles of Dereth Calendar: a tour of the art and architecture of Asheron's Call http://www.lulu.com/content/77264 -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.10.18/86 - Release Date: 31/08/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.10.18/86 - Release Date: 31/08/2005
[sqlite] Re: Thread safety guarantees
Christopher R. Palmer wrote: Unfortunately, that's not the case. The code that was being used when I created ticket 1272 was very simple. In the main thread, I opened a handle for each thread. Each thread then worked independently using only their own handle. This broke the locking because the low-level Linux file locks are tied to the thread that created them. That is, the thread that opened the handle.. So SQLite locks the DB file immediately after opening a connection in sqlite_open? If all activity on the connection must be restricted to a single thread, how is one to properly use sqlite3_interrupt? Igor Tandetnik
Re: [sqlite] Thread safety guarantees
On 9/4/05, Christopher R. Palmer <[EMAIL PROTECTED]> wrote: > > Unfortunately, that's not the case. The code that was being used when I > created ticket 1272 was very simple. In the main thread, I opened a > handle for each thread. Each thread then worked independently using > only their own handle. This broke the locking because the low-level > Linux file locks are tied to the thread that created them. That is, the > thread that opened the handle.. > > I meant a simpler case: a *single* handle per database per process. All threads share the same single handle but only one thread uses it at any time. There shouldn't be any inter-thread locking problems with this case. Ron
Re: [sqlite] Thread safety guarantees
Ron Avriel wrote: On 9/3/05, D. Richard Hipp <[EMAIL PROTECTED]> wrote: This is not portable. Some operating systems (ex: RedHat) will cause intermittent problems if the same SQLite handle is used by more than one thread. The program will seem to work initially but will begin to exhibit unreproducible errors under heavy load. This is a problem in the design of the operating system and there is nothing that SQLite can do to prevent it. In order to avoid these problems and for your software to be portable, each SQLite handle must be used by only a single thread - specifically the thread that opened it. If you want to use SQLite in a multi- threaded application, then open a separate handle for each thread. As I understand from all previous Linux multithreading problems http://www.sqlite.org/cvstrac/tktview?tn=1272 http://www.sqlite.org/cvstrac/chngview?cn=2521 http://www.sqlite.org/cvstrac/tktview?tn=1285 they were all caused by *simultaneous* use of the same handle in different threads. If the application ensures that a handle is used to execute queries by *only one thread at a time*, as mentioned in level 2 above, I don't see any reason for multihreading problems. Unfortunately, that's not the case. The code that was being used when I created ticket 1272 was very simple. In the main thread, I opened a handle for each thread. Each thread then worked independently using only their own handle. This broke the locking because the low-level Linux file locks are tied to the thread that created them. That is, the thread that opened the handle.. Cheers, Chris.
Re: [sqlite] Thread safety guarantees
On 9/3/05, D. Richard Hipp <[EMAIL PROTECTED]> wrote: > > This is not portable. Some operating systems (ex: RedHat) > will cause intermittent problems if the same SQLite handle > is used by more than one thread. The program will seem to > work initially but will begin to exhibit unreproducible > errors under heavy load. This is a problem in the design > of the operating system and there is nothing that SQLite > can do to prevent it. In order to avoid these problems and > for your software to be portable, each SQLite handle must > be used by only a single thread - specifically the thread > that opened it. If you want to use SQLite in a multi- > threaded application, then open a separate handle for > each thread. > As I understand from all previous Linux multithreading problems http://www.sqlite.org/cvstrac/tktview?tn=1272 http://www.sqlite.org/cvstrac/chngview?cn=2521 http://www.sqlite.org/cvstrac/tktview?tn=1285 they were all caused by *simultaneous* use of the same handle in different threads. If the application ensures that a handle is used to execute queries by *only one thread at a time*, as mentioned in level 2 above, I don't see any reason for multihreading problems. I think that the new multihreading restriction from version 3.2.5, described as level 1 above, imposes a very hard limitation. It's impractical for my multithreaded Linux application to open many hundreds of handles instead of around ten. If SQLite wants to ensure it is not being abused can't it check multithreading abuse from sqlite3_prepare() until sqlite3_step() as in level 2 above, thus enabling a serialized handle pool? I've tested SQLite heavily in a multithreaded Linux application with a serialized access of all threads to a single handle and encountered no problems. On the other hand, would it be safe to compile SQLite with -DTHREADSAFE=0, thus disabling thread checks, and use a serialized handle pool in a multithreaded Linux application? Thanks, Ron
