DATA RACE: Found in sqlite3.c
(1) By Zu-Ming Jiang (jiang446079653) on 2020-04-29 02:14:31 [source]
Dear SQLite developers:
I used my fuzz-testing tool, connzer, to detect data race in SQLite. Here is a data race found by connzer. I wish you can help me check whether it is a real race, thanks!!
The following is the race report.
Race report
Race object: pInfo->nBackfill
Thread 1:
Access: pInfo->nBackfill==pWal->hdr.mxFrame
Line number: sqlite3.c, 61048
Call stack:
walTryBeginRead()
sqlite3WalBeginReadTransaction()
pagerBeginReadTransaction()
sqlite3PagerSharedLock()
lockBtree()
sqlite3BtreeBeginTrans()
sqlite3VdbeExec()
sqlite3Step()
sqlite3_step()
execsql_i64_x()
walthread3_thread()
launch_thread_main()
Lock:
- None
Thread 2:
Access: pInfo->nBackfill = 0;
Line number: sqlite3.c, 60269
Call stack:
walRestartHdr()
walRestartLog()
sqlite3WalFrames()
pagerWalFrames()
sqlite3PagerCommitPhaseOne()
sqlite3BtreeCommitPhaseOne()
vdbeCommit()
sqlite3VdbeHalt()
sqlite3VdbeExec()
sqlite3_step->sqlite3Step()
execsql_i64_x()
walthread3_thread()
launch_thread_main()
Lock:
- None
My fuzzer finds that these 2 accesses can be executed concurrently, and they are not protected by any lock, so my fuzzer report this race.
(2) By Zu-Ming Jiang (jiang446079653) on 2020-05-02 07:28:58 in reply to 1 [link] [source]
What do you think about this data race?
(3) By Richard Hipp (drh) on 2020-05-02 11:33:14 in reply to 2 [link] [source]
I believe your analysis is incorrect.
pInfo->nBackfill
is part of a shared-memory segment that is visible
to multiple processes. Access to that shared-memory segment is serialized
using file locks, not mutexes. Perhaps your tool only looks at mutexes
and fails to properly account for the affect of file locks.
(4) By Zu-Ming Jiang (jiang446079653) on 2020-05-03 01:59:01 in reply to 3 [link] [source]
Yes, you are right. File locks is not considered.
Thanks for your response.
(5) By Zu-Ming Jiang (jiang446079653) on 2020-05-13 10:42:45 in reply to 3 [link] [source]
I think there may be some problem in your file locks.
To check whether the race is real, I set breakpoints before these two accesses when they are running in the call stack described above. I find that the breakpoints can be activated simultaneously, and the address of race variables are same. I think these result can prove that the race actually happens. So these accesses is not serialized successfully.
(8) By Wout Mertens (wmertens) on 2020-05-20 08:52:44 in reply to 5 [link] [source]
Do you mean that you tested this with working file locks, and it triggers the breakpoints simultaneously?
I think the reason you're not getting replies is because it requires very specic knowledge to verify your findings, and most of us don't have it.
If you could post a step-by-step of how to reproduce, that would really help!
(6) By Zu-Ming Jiang (jiang446079653) on 2020-05-14 12:25:30 in reply to 3 [link] [source]
Could you confirm this race? Because I have successfully reproduced this race by using breakpoints, I think there may be some problems in the file locks.
(7) By Zu-Ming Jiang (jiang446079653) on 2020-05-19 10:29:00 in reply to 3 [link] [source]
I think it is a real race because I have reproduced it. Please help me confirm it.