tsan_arangodb_suppressions.txt

race:boost/lockfree/queue.hpp
race:boost/lockfree/detail/freelist.hpp
race:boost::lockfree::queue

# These operators contain an assertion that checks the refCount.
# That read operation is racy, but since it is just an assert we don't care!
race:SharedAqlItemBlockPtr::operator*
race:SharedAqlItemBlockPtr::operator->

# logCrashInfo calls LOG_TOPIC which in turn calls std::string::reserve
signal:lib/Basics/CrashHandler.cpp
signal:crashHandlerSignalHandler

# accesses to the function pointers can be racy
# this is most likely benign, but strictly speaking it is still UB so should be
# addressed eventually
race:3rdParty/velocypack/src/asm-functions.cpp
race:doInitCopy
race:doInitCopyCheckUtf8
race:doInitSkip
race:doInitValidateUtf8String

# A compiler optimization in DBImpl::ReleaseSnapshot() produces code where a
# register is populated with different addresses based on some condition, and
# this register is later read to populate the variable `oldest_snapshot`.
# However, this generated read is a non-atomic read, which therefore results in
# a false positive race warning. I have created an according GitHub issue:
# https://github.com/google/sanitizers/issues/1398
race:VersionSet::SetLastSequence

# TODO - this should be removed once BTS-685 is fixed
race:AllowImplicitCollectionsSwitcher
race:graph::RefactoredTraverserCache::appendVertex

# Known false-positive, see https://github.com/google/sanitizers/issues/953
race:absl/synchronization/internal/waiter.cc
race:absl::synchronization_internal::Waiter

# TODO Fix known thread leaks
thread:ClusterFeature::startHeartbeatThread
thread:CacheManagerFeature::start
thread:DatabaseFeature::start

# TODO Fix lock order inversion
deadlock:consensus::Agent::setPersistedState

# TODO Fix data race in arangodbtests
race:DummyConnection::sendRequest

# TODO It's "false positive" caused by code:
# 1. ctx_lock lock
# 2. ctx_lock unlock; wait_for on ctx_lock; ctx_lock lock
# 3. s[i].flush_mutex lock
# 4. ctx_lock unlock; wait_for on ctx_lock; ctx_lock lock
# 5. s[i + 1].flush_mutex lock
# It should be fixed in future, because current code doing a lot unnecessary stuff
deadlock:iresearch::index_writer::flush_pending