blob: 5b364bcc49749972bcd25b5e4202c3082cb24998 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
|
# 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 exclusive lock on attribute E, blocked by thread A
# Thread D trying to get 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 external code that we do not control. Complains that mutex
# creation and locking is not strictly enough 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 is not strictly enough 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 datastructures, 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
|
