Yes, retry on SQLITE_SCHEMA solve the problem. Should the FAQ be updated?
BTW, I found that the huge number of data race warnings can easily be
removed. The found races are benign--it just assign same static mutex id
whenever pthreadMutexAlloc() is called. by not assigning the mutex id once
it is initialized -- as in MAKE_DRD_HAPPY --, most of race warnings are
removed.
static sqlite3_mutex *pthreadMutexAlloc(int iType){
static sqlite3_mutex staticMutexes[] = {
...
...
default: {
assert( iType-2 >= 0 );
assert( iType-2 < ArraySize(staticMutexes) );
p = &staticMutexes[iType-2];
#if MAKE_DRD_HAPPY
if ( p->id == 0 ) // first call
p->id = iType; // initialize
else
assert(p->id == iType);
#else /* original */
p->id = iType;
#endif
break;
}
}
return p;
}
On Mon, Jul 19, 2010 at 11:36 AM, Dave Toll <dave.t...@opentv.com> wrote:
> Hi Heechul
>
> I have used this test code as well, and I found that you have to treat
> SQLITE_SCHEMA the same way as SQLITE_LOCKED - you should retry the operation
> that returned this error. I believe it indicates that the master table is
> locked by another thread due to a DDL command (e.g. CREATE TABLE, DROP
> TABLE). It does seem to contradict FAQ #15.
>
> Anyone else, please feel free to correct me if I'm wrong - I use code that
> makes this assumption and I hope I haven't messed something up... I should
> mention that I am using shared cache mode.
>
> Cheers,
> Dave.
>
>
> -----Original Message-----
> From: Heechul [mailto:heechul....@gmail.com]
> Sent: Sunday, July 18, 2010 10:15 AM
> To: sqlite-users@sqlite.org
> Subject: [sqlite] bug report: data race in multi-threaded execution
> ofsqlite3
>
>
> 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
>
--
Heechul
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
