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.