I see. I think that makes sense! I've gone ahead and added these 2 functions to our local Tsan blacklist then. In researching this further, I found one more Tsan issue here in walTryBeginRead:
- One thread is here: http://www.sqlite.org/src/artifact/aa9cffc7a2bad?ln=2558 - One thread is here: http://www.sqlite.org/src/artifact/aa9cffc7a2bad?ln=2571 Is this one expected as well? If so, I'll also add this function to our blacklist. Thanks again! Ben On Wed, May 23, 2018 at 1:24 AM, Dan Kennedy <danielk1...@gmail.com> wrote: > On 05/23/2018 06:21 AM, Ben Asher wrote: > >> Hi there! I believe I've found a SQLite bug that triggers TSAN. I'm hoping >> to either confirm this bug or learn what I'm doing wrong. Some background: >> in our code, we make sure to synchronize writes to our database such that >> only one write can happen at any given time for the same database in our >> application (i.e. there's one synchronized writer connection). However, we >> allow any number of reads (readers create their own connections, which are >> similarly not shared with other threads) to happen on the same database >> (with a cap on the number of connections to respect resource limits). >> Additionally, the database has PRAGMA journal_mode=WAL; set. At the moment >> when TSAN is triggered, there is one reader and one writer each with their >> own connection to the same db performing a read and a write: >> >> - Reader is running: sqlite3WalFindFrame, specifically the line with this >> code (line 59679 in my sqlite.c): >> >> for(iKey=walHash(pgno); aHash[iKey]; iKey=walNextHash(iKey)){ >> >> >> - Writer is running walIndexAppend, specifically the line with this code >> (line 57856 in my sqlite.c): >> > > Thanks for the thread-testing. This one is a known condition. Tsan can't > see it, but we think it is safe. See the comment above the block in > sqlite3WalFindFrame() for details: > > http://www.sqlite.org/src/artifact/aa9cffc7a2bad?ln=2859..2883 > > Basically the race condition is only on the append-only hash-table. But > the hash-table is only used to accelerate lookups on the aPgno[] array. And > since the hash-table is append-only, it can only produce false-positives > (which are filtered out when aPgno[] is inspected). > > Dan. > > > > > >> aHash[iKey] = (ht_slot)idx; >> >> >> I apologize if those line numbers aren't helpful, however I hope the >> function names + code are unique enough to locate the lines in question. >> This is sqlite3 version 3.23.1. >> >> Please let me know if there's any other information I can provide. Thanks! >> >> Ben >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users@mailinglists.sqlite.org >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >> > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > -- Ben _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
