Bug report: Potential thread safety issues in sqlite3_initialize

Oystein Eftevaag <[email protected]>
Newsgroups gmane.comp.db.sqlite.general
Message-ID <CAEkU82w5oYUSV2GMLkg5-_RsYt_du2EvTFu_k2MvDGRHtnMK0Q@mail.gmail.com>
Hi folks,

Data races in sqlite3_initialize was previously reported in
https://www.mail-archive.com/[email protected]/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/[email protected]/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
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.