1 # This file lists the functions, object files and source files
2 # which should be ignored (i.e. not instrumented) by ThreadSanitizer.
3 # See http://code.google.com/p/data-race-test/wiki/ThreadSanitizerIgnores.
5 # ignore these libraries
9 # we ignore the whole NSS library for now since
10 # its instrumentation is very slow.
11 # TODO(timurrrr): investigate whether we need to instrument it
15 # ignore pulseaudio - We don't have symbols there and it can be slow otherwise
18 # ignore this standard stuff
23 fun_r:_pthread_free_pthread_onstack
33 # dark magic with 'errno' here.
36 # ignore libc's printf functions
41 # False reports on std::string internals, see
42 # http://code.google.com/p/data-race-test/issues/detail?id=40
44 fun_r:*_M_set_length_and_sharable*
50 # Comparison of std::strings sometimes takes a lot of time but we don't really
51 # need precise stack traces there.
52 fun_hist:_ZStltIcSt11char_traitsIcESaIcEEbRKSbIT_T0_T1_ES8_
53 fun_hist:_ZNKSs7compareERKSs
55 # Don't instrument intercepts
56 src:*ts_valgrind_intercepts.c
58 ##################################################################
59 # Don't instrument synchronization code
60 src:*base/threading/thread_local_storage*
61 src:*base/stats_counters*
62 src:*base/synchronization/condition_variable*
63 src:*base/synchronization/lock*
64 src:*base/synchronization/waitable_event*
66 # Don't instrument code dealing with atomics (base::subtle)
67 fun:*base*subtle*Release_Store*
68 fun:*base*subtle*NoBarrier_CompareAndSwap*
69 fun:*base*subtle*NoBarrier_Load*
70 # Keep some mangling so we don't match NoBarrier_AtomicIncrement
71 fun:*base*subtle23Barrier_AtomicIncrement*
73 # MD5 computations are very slow due since sums are computed by
74 # repeatedly calling tiny functions and is unlikely to race with
78 # Don't instrument tcmalloc
81 # This function is heavy in net_unittests
82 fun_r:*disk_cache*BackendImpl*CheckAllEntries*
84 # V8 is a hot-spot under ThreadSanitizer.
85 # Lots of tiny functions there...
87 # Can we miss data races on V8 objects due to non thread-safe API calls
88 # if we don't instrument v8::internals?
91 # unibrow namespace contains lots of tiny unicode conversion functions.
94 # Histogram has tiny functions that can be called frequently
96 # Recursively ignore Histrogram::Add and friends, see http://crbug.com/62694.
97 fun_r:*4base*9Histogram*3Add*
98 fun_r:*4base*16HistogramSamples*3Add*
99 fun_r:*4base*13HistogramBase*7AddTime*
101 # TODO(timurrrr): SKIA - needs separate testing?
102 # SKIA unittest is single-threaded...
103 # SKIA uses un-annotated atomic refcount and other sync stuff
104 # some functions are HEAVY like png, jpeg decoding
105 src:*third_party/skia*
110 # This function generates 25% of memory accesses in net_unittests
111 fun:*icu_4_2*UnicodeSet*add*
113 # SQLite has lots of tiny functions and produce too many segments on some tests.
114 # See http://crbug.com/56511
117 # There's some weird failure test going on in this tiny test function in sqlite
118 fun_r:threadLockingTest
120 # Ignore accesses below GetCurrentThreadIdentifier.
121 # There is a benign race which is hard to suppress properly,
122 # see http://crbug.com/44580
123 fun_r:*BrowserThread*GetCurrentThreadIdentifier*
125 # BrowserThread accesses MessageLoop::current() in ::CurrentlyOn.
126 # We can't use suppressions to hide these reports since the concurrent stack
127 # is simply "base::Thread::ThreadMain"
128 # See http://crbug.com/63678
129 fun_r:*BrowserThread*CurrentlyOn*
131 # zlib is smarter than we are, see http://www.zlib.net/zlib_faq.html#faq36
133 # zlib-related reports, not investigated yet. See http://crbug.com/70932
134 fun_r:*remoting*CompressorZlib*Process*
136 # X11 reads the _XErrorFunction callback in a racey way, see
137 # http://crbug.com/65278
140 fun:*IPC*Logging*Enable*
141 fun:*IPC*Logging*Disable*
143 # TSan doesn't support lockf and hence shared memory locks in this function;
144 # http://crbug.com/45083
145 fun_r:*base*StatsTable*AddCounter*
147 # TSan doesn't understand internal libc locks, see http://crbug.com/71435
150 # gethostbyname2_r is thread-safe, however ThreadSanitizer reports races inside it and
151 # (sometimes) in __nss_* functions below it.
152 # This may be related to
153 # https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/59449
154 fun_r:gethostbyname2_r*
156 # TODO(timurrrr): remove this when TSan is updated past r3232
159 # Strange reports below _IO_getline, every time in "Concurrent access".
160 # Probably the reports are there since we're missing the libc internal locks
163 # A benign race in glib on something called "contention_counter".
166 # A benign race in glibc on "random_time_bits".
169 # A probably-benign race on '__have_o_cloexec' in opendir/__alloc_dir,
170 # see http://crbug.com/125928.
174 # The sqlite cache is racing against a few different stacktraces,
175 # so let's ignore it recursively. See http://crbug.com/84094
178 # "Suppress" a data race in TraceLog::GetCategory which has
179 # fun:MessageLoop::RunTask at the top of the "current" stack which we don't want
180 # to suppress. See http://crbug.com/98926
181 fun:*base*debug*TraceLog*GetCategoryInternal*
183 # libc threading on GCC 4.6
184 fun:arena_thread_freeres
186 # __strncasecmp_l_ssse3 overreads the buffer causing TSan to report a data race
187 # on another object. See http://crbug.com/177074