# lock-order-inversion (libmosek64.*) in lc_auth_data
deadlock:lc_auth_data

# unlock of an unlocked mutex (libmosek64.*) in l_mt_unlock
mutex:l_mt_unlock

# unlock of an unlocked mutex (libmosek64.*) in lc_checkout
mutex:lc_checkout

# The OpenMP runtime bundled with MOSEK has not been generated with TSan support on. https://reviews.llvm.org/D13072
# data race (libiomp5.*) in __kmp_resume
race:__kmp_resume

# data race (libiomp5.*) in __kmp_suspend_uninitialize_thread
race:__kmp_suspend_uninitialize_thread

# data race (libiomp5.*) in __kmp_launch_monitor
race:__kmp_launch_monitor

# thread leak (libiomp5.*) in __kmp_create_worker
thread:__kmp_create_worker

# thread leak (libiomp5.*) in __kmp_create_monitor
thread:__kmp_create_monitor

# data race libmosek64.so.10.1.  MOSEK has not been instrumented with TSan.
called_from_lib:libmosek64.so.10.1

# data race (libglib-2.0.*) in g_static_rec_mutex_lock
race:g_static_rec_mutex_lock

# data race (libgurobi100.*) in bio_asn1.c.  Gurobi has not been instrumented
# with TSan.
called_from_lib:libgurobi.so
called_from_lib:libgurobi100.dylib
called_from_lib:libgurobi100.so

# data race in libtbb.so.  libtbb has not been instrumented with TSan.
called_from_lib:libtbb.so

# leak in libtbb.so
thread:libtbb.so

# thread leak in libembree3.so.  libembree3 has not been instrumented with TSan.
called_from_lib:libembree3.so

# Somehow libtbb appears to be trying to release a thread twice, the
# second time inside a global destructor.
race:__cxa_finalize
mutex:__cxa_finalize

# Issue #16494.
race:drake_vendor::vtkNew<drake_vendor::vtkRenderWindow>::~vtkNew

# In the lcm_memq handler, while correctly holding a mutex it obtains exclusive
# access to the next message by popping it off of the queue, but then it
# releases the mutex before passing the message along to the user code.  TSan
# does not understand the ownership (exclusivity) transfer of the message so
# reports false positive races during the "pass along to the user".
#
# TODO(jwnimmer-tri) Unfortunately, this suppresses any races with
# lcm_memq_handle in the call stack anywhere, which includes the user's
# callback handlers.  To suppress only *inside* of this one problematic
# function, we'd need to use a tsan.blacklist file, but that's currently
# a TODO in our dynamic_analysis/bazel.rc.  Once our toolchain supports
# a blacklist, we should use it instead of this.
race:^lcm_memq_handle$
