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 ##
**Version:** 3.30.1
**Race object:** `pDbFd->pInode->pShmNode`
**Thread 1:**
**Access:** `pDbFd->pInode->pShmNode = pShmNode;`
**Line number:** `sqlite3.c; 37255`
**Call stack:**
1. `unixOpenSharedMemory()`
2. `unixShmMap()`
3. `sqlite3OsShmMap()`
4. `walIndexPageRealloc()`
5. `walIndexPage()`
6. `walIndexReadHdr()`
7. `walTryBeginRead()`
8. `sqlite3WalBeginReadTransaction()`
9. `pagerBeginReadTransaction()`
10. `sqlite3PagerSharedLock()`
11. `lockBtree()`
12. `sqlite3BtreeBeginTrans()`
13. `sqlite3InitOne()`
14. `sqlite3Init()`
15. `sqlite3ReadSchema()`
16. `sqlite3Pragma()`
17. `yy_reduce()`
18. `sqlite3Parser()`
19. `sqlite3RunParser()`
20. `sqlite3Prepare()`
21. `sqlite3LockAndPrepare()`
22. `sqlite3_prepare_v2()`
23. `sqlite3_exec()`
24. `opendb_x()`
25. `walthread1_thread()`
26. `launch_thread_main()`
**Lock:** `unixEnterMutex();`
**Thread 2:**
**Access:**
`pShmNode = pFile->pInode->pShmNode;`
**Line number:** `sqlite3.c, 36994`
**Call stack:**
1. `unixShmSystemLock()`
2. `unixShmLock()`
3. `sqlite3OsShmLock()`
4. `walLockExclusive()`
5. `walIndexReadHdr()`
6. `walTryBeginRead()`
7. `sqlite3WalBeginReadTransaction()`
8. `pagerBeginReadTransaction()`
9. `sqlite3PagerSharedLock()`
10. `lockBtree()`
11. `sqlite3BtreeBeginTrans()`
12. `sqlite3InitOne()`
13. `sqlite3Init()`
14. `sqlite3Pragma()`
15. `sqlite3ReadSchema()`
16. `yy_reduce()`
17. `sqlite3Parser()`
18. `sqlite3RunParser()`
19. `sqlite3Prepare()`
20. `sqlite3LockAndPrepare()`
21. `sqlite3_prepare_v2()`
22. `sqlite3_exec()`
23. `opendb_x()`
24. `walthread1_ckpt_thread()`
25. `launch_thread_main()`
**Lock:** `sqlite3_mutex_enter(pShmNode->pShmMutex);`
**Impact:** This race may cause serious consequence: if the race access in thread 2 is executed before the race access in thread 1, `pShmNode` in `unixShmSystemLock()` in thread 2 will become NULL, and `pShmNode->nRef` will cause Null dereference.
My fuzzer finds that these 2 accesses can be executed concurrently, and they are protected by different locks, so my fuzzer report this race.