Hi, I think there are data races that cause problems when running multi-threaded applications.
I downloaded sqlite-3.6.23.1 source distribution and tested a multi-threaded program found in test/threadtest1.c (slightly modified due to obvious errors in original code) on my Intel Core2Quad running ubutu 10.04 (2.6.32-23-generic #37-Ubuntu SMP) I compiled it as follows. $ gcc -DSQLITE_OMIT_LOAD_EXTENSION=1 -DTHREADSAFE=1 -g -o threadtest-bugreport -lpthread threadtest-bugreport.c ../sqlite3.c The code simply create multiple threads each performs the following sequences: open db create table insert 100 entries select drop table For every two thread work on the same datafile file but work on different table. For example, thread 1 and thread 2 open the same "testdb-1". but thread 1 create "t1" table and thread 2 create "t2" table. Example of correct run is as follows: $ ./threadtest-bugreport 10 10 threads 2.testdb-2: END 1.testdb-5: END 2.testdb-4: END 1.testdb-3: END 1.testdb-2: END 1.testdb-4: END 2.testdb-5: END 1.testdb-1: END 2.testdb-1: END 2.testdb-3: END However, I got following intermittent errors $ ./threadtest-bugreport 10 10 threads 1.testdb-3: command failed: DROP TABLE t1; - database schema has changed Exit with code 1 All operations are performed using sqlite3_exec() API, Therefore, according to FAQ (q.15), I should not see SQLITE_SCHEMA error at least. Then, I used valgrind data-race detector (valgrind --tools=drd) and found lots of data races as follows: valgrind --tool=drd ./threadtest-bugreport 2 ==23995== drd, a thread error detector ==23995== Copyright (C) 2006-2009, and GNU GPL'd, by Bart Van Assche. ==23995== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==23995== Command: ./threadtest-bugreport 2 ==23995== 2 threads ==23995== Thread 2: ==23995== Conflicting store by thread 2 at 0x080c2058 size 4 ==23995== at 0x804D3E3: pthreadMutexAlloc (sqlite3.c:15601) ==23995== by 0x804D270: sqlite3MutexAlloc (sqlite3.c:14918) ==23995== by 0x8052D06: unixEnterMutex (sqlite3.c:22329) ==23995== by 0x8054828: fillInUnixFile (sqlite3.c:25756) ==23995== by 0x805518B: unixOpen (sqlite3.c:26272) ==23995== by 0x804CC3A: sqlite3OsOpen (sqlite3.c:12604) ==23995== by 0x805ADD6: sqlite3PagerOpen (sqlite3.c:35419) ==23995== by 0x805F668: sqlite3BtreeOpen (sqlite3.c:40349) ==23995== by 0x80B5D4E: sqlite3BtreeFactory (sqlite3.c:97729) ==23995== by 0x80B65EF: openDatabase (sqlite3.c:98123) ==23995== by 0x80B67D2: sqlite3_open (sqlite3.c:98237) ==23995== by 0x8049698: worker_bee (threadtest-bugreport.c:205) ==23995== Allocation context: BSS section of ul/Papers/cs523/dpthread/papps/sqlite/test/threadtest-bugreport ==23995== Other segment start (thread 3) ==23995== at 0x402D531: pthread_mutex_lock (drd_pthread_intercepts.c:580) ==23995== by 0x804D419: pthreadMutexEnter (sqlite3.c:15660) ==23995== by 0x804D2AE: sqlite3_mutex_enter (sqlite3.c:14936) ==23995== by 0x8052D0E: unixEnterMutex (sqlite3.c:22329) ==23995== by 0x8054CB0: findReusableFd (sqlite3.c:26010) ==23995== by 0x8054E95: unixOpen (sqlite3.c:26119) ==23995== by 0x804CC3A: sqlite3OsOpen (sqlite3.c:12604) ==23995== by 0x805ADD6: sqlite3PagerOpen (sqlite3.c:35419) ==23995== by 0x805F668: sqlite3BtreeOpen (sqlite3.c:40349) ==23995== by 0x80B5D4E: sqlite3BtreeFactory (sqlite3.c:97729) ==23995== by 0x80B65EF: openDatabase (sqlite3.c:98123) ==23995== by 0x80B67D2: sqlite3_open (sqlite3.c:98237) ... ... 1.testdb-1: command failed: CREATE TABLE t1(a,b,c); - database schema has changed Exit with code 1 ==23995== ==23995== For counts of detected and suppressed errors, rerun with: -v ==23995== ERROR SUMMARY: 990 errors from 7 contexts (suppressed: 47 from 37) I believe this is a bug. please check if it is the case. Best Heechul
_______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
