> 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.
All race warnings in any tool detecting that should be considered as
warnings which have a very good probability of false positive. And in
this particular case it probably easy fixable but it makes worse
readable code without any benefit. Then why it should be done?
You can run your application with --tool=helgrind and see how many
complaints it will give for the code inside pthread_mutex_lock. And
all of them are false positives.
Pavel
On Mon, Jul 19, 2010 at 5:36 PM, heechul Yun <heechul....@gmail.com> wrote:
> 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
>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
