Hi folks, Data races in sqlite3_initialize was previously reported in https://www.mail-archive.com/sqlite-users@mailinglists.sqlite.org/msg94225.html and a fix landed, however while investigating internal TSan reports of this, as far as we can tell the issue is still present (on non-x86 platforms with less memory ordering guarantees) as mentioned previously in https://www.mail-archive.com/sqlite-users@mailinglists.sqlite.org/msg94225.html .
Specifically, in sqlite3MutexInit() sqlite3GlobalConfig.mutex.xMutexAlloc can be read as being set on a core, while the rest of the initialization done in sqlite3MutexInit() still is being read as unset. The same is true for sqlite3GlobalConfig.isInit within sqlite3_initialize(); a core calling the function concurrently with another, could see sqlite3GlobalConfig.isInit as set while the rest of the init work done is still seen as unset. This is due to the current memory barriers ordering the writes, but there's no barriers ensuring that other cores haven't done the loads out of order. Thanks, Oystein _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
