The line numbers in this report don't seem to make much sense: > Read of size 4 at 0x55c2f79772f8 by thread T4 (mutexes: write M509514):#0 sqlite3VdbeExec /home/lewis/Sandbox/Stroika-Build-Dir-Ubuntu1804_x86_64/IntermediateFiles/g++-debug-sanitize_thread/ThirdPartyComponents/sqlite/sqlite3.c:88607 (Test36+0x492c1b1) > > withPrevious write of size 4 at 0x55c2f79772f8 by thread T3 (mutexes: write M508861):#0 sqlite3WritableSchema /home/lewis/Sandbox/Stroika-Build-Dir-Ubuntu1804_x86_64/IntermediateFiles/g++-debug-sanitize_thread/ThirdPartyComponents/sqlite/sqlite3.c:114046 (Test36+0x4a111a5) > > > The conflict appears as follows:testcase( pIn1->flags & MEM_Int ); // READ IN ONE THREAD Fair enough - but *pIn1 is part of the VM being run. No other thread should be able to get near it, with or without a mutex. > after write:testcase( (db->flags&(SQLITE_WriteSchema|SQLITE_Defensive))==0 ); IN ANOTHER THREAD And this isn't actually a write. Or anywhere near anything that should be touching anything accessed by the other thread. Do any of the other valgrind modules show any complaints with this test? Can you try to get the same stack traces etc. from a non-optimized binary? Thanks, Dan.