tsan-suppressions.txt

# There is an explicit (and documented) mutex order inversion in the MergeThrottler component
# that cannot cause a deadlock in practice due to separately maintained invariants for when the
# mutexes can be locked. Of course, TSan is not able to infer this by itself, so silence this
# particular warning.

deadlock:storage::MergeThrottler::onFlush

# We hold the attribute context lock when getting a shared lock on
# enumerated attributes to prevent references to enumerated values
# from being changed due to compaction while performing grouping on
# the attribute. Thus we have an apparent lock order cycle between the
# attribute context lock and the shared lock on each attribute.
#
# We use an interlock to ensure that only one thread at a time tries
# to get an exclusive lock on an enumerated attribute (before
# compacting the enum store). Without that interlock, we could get a
# deadlock with
#
# Thread A having shared lock on attribute E and trying to get a shared lock
#          on attribute F, blocked by thread D.
# Thread B having shared lock on attribute F and trying to get a shared lock
#          on attribute E, blocked by thread C.
# Thread C trying to get an exclusive lock on attribute E, blocked by thread A
# Thread D trying to get an exclusive lock on attribute F, blocked by thread B

deadlock:search::AttributeContext::getAttribute
deadlock:search::AttributeContext::getAttributeStableEnum
deadlock:proton::ImportedAttributesContext::getAttribute
deadlock:proton::ImportedAttributesContext::getAttributeStableEnum

# This is an external code that we do not control. Complains that mutex
# creation and locking are not strictly ordered.

race:llvm::sys::MutexImpl
race:llvm::sys::SmartMutex<false>::lock
race:llvm::sys::SmartMutex<true>::lock
race:llvm::sys::DynamicLibrary::getPermanentLibrary
race:(anonymous namespace)::GDBJITRegistrationListener::notifyObjectLoaded

# This is external code that we do not control. Complains that mutex
# creation and locking are not strictly ordered.

race:re2::Prog::GetDFA
race:re2::DFA::DFA

# Non-TSAN instrumented OpenSSL may trigger warnings when many threads are attempting
# to create TLS connections at once in a newly started process. This appears to be related
# to implicit init-once semantics of internal OpenSSL data structures, though the TSAN report
# stack frames are truncated and don't show the full picture.
# When a TSAN-instrumented OpenSSL build is used, the error does not manifest itself.
# This implies that it's likely caused by a lack of instrumentation of atomic operations
# (acquire-load in double-checked locking etc).
race:ASN1_STRING_cmp
race:ASN1_STRING_set