# This is a list of suppressions for ThreadSanitizer. Anything listed here will be
# ignored during testing. See https://github.com/google/sanitizers/wiki/ThreadSanitizerSuppressions
# for documentation on how this file works.

# There's a bug in libstdc++ that causes ThreadSanitizer to flag this as a data race.
# See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77704. Ignore any reports from this
# as it's really really noisy, and there's not much we can do to fix it.
race:std::ctype<char>::narrow

# =====================================================================
# Everything below here are known failures in Zeek. These are here until they
# can be fixed, just so we can get the ThreadSanitizer builds running on Cirrus
# and catch anything new. If we can't fix something in this list (possibly the
# sqlite ones?) split them out into a separate block above here with a comment
# as to why.

race:broker::internal::connector::run_impl
race:caf::net::multiplexer::set_thread_id
race:caf::action::run
mutex:caf::detail::ringbuffer<std::unique_ptr<caf::detail::thread_safe_actor_clock::schedule_entry, std::default_delete<caf::detail::thread_safe_actor_clock::schedule_entry> >, 64ul>::push_back

# This one causes supervisor.config-bare-mode to fail occasionally but not always
signal:caf::actor_control_block::enqueue

# There's a bunch of failures down inside the sqlite code itself, mostly
# around opening the database in the SQLite input reader and the SQLite
# logging writer.
race:sqlite3MutexInit
race:sqlite3Malloc
race:sqlite3_mutex_enter
race:sqlite3_initialize

# This one isn't actually in sqlite code, but some StringVal object gets ref'd by
# zeek::id::find_const and throws a data race.
race:zeek::logging::writer::detail::SQLite::DoInit

# These findings were suppressed after the CI build was upgraded to Ubuntu 22.04.
# They weren't reported by prior compiler versions.
race:zeek::threading::MsgThread::RetrieveIn
race:zeek::threading::MsgThread::Run
race:zeek::threading::InputMessage<zeek::threading::MsgThread>::Object
mutex:zeek::threading::Queue<zeek::threading::BasicInputMessage*>::Put
mutex:zeek::threading::Queue<zeek::threading::BasicInputMessage*>::LocksForAllQueues
deadlock:zeek::threading::Queue<zeek::threading::BasicInputMessage*>::LocksForAllQueues

# This only happens at shutdown. It was supposedly fixed in civetweb, but has cropped
# up again. See https://github.com/civetweb/civetweb/issues/861 for details.
race:mg_stop

# Uninstrumented library.
#
# We'd need to build zmq with TSAN enabled, without it reports data races
# as it doesn't see the synchronization done [1], but also there's reports
# that ZeroMQ uses non-standard synchronization that may be difficult for
# TSAN to see.
#
# [1] https://groups.google.com/g/thread-sanitizer/c/7UZqM02yMYg/m/KlHOv2ckr9sJ
# [2] https://github.com/zeromq/libzmq/issues/3919
#
called_from_lib:libzmq.so.5
called_from_lib:libzmq.so

# After adding encryption support, TSAN reported a race originating here:
#
#    Previous write of size 6 at 0x72a40004b01a by thread T3:
#      #0 memmove <null> (zeek+0x1c5e542) (BuildId: dd9dfefe43a60c58)
#      #1 crypto_secretbox_open_detached <null> (libsodium.so.23+0x2b74b) (BuildId: e6c6c4e9f51d2fa8ee52c3e03acfa1e765f35c32)
#
# ...against a read of the message buffers from a successful zmq_msg_recv() call.
#
# crypto_secretbox_open_detached() is called from ZeroMQ's internal IO thread
# for decryption purposes via the following callstack:
#
# zmq::curve_encoding_t::decode()            libzmq
#  -> crypto_box_open_easy_afternm()         libsodium
#    -> crypto_box_open_detached_afternm()   libsodium
#      -> crypto_secretbox_open_detached()   libsodium
#
# We already ignore libzmq.so wholesale, but on a default build on Ubuntu 24.04
# the stack doesn't contain libzmq.so and so TSAN doesn't pick up on the suppression.
# The T3 thread above is/was a ZMQ IO thread.
#
# Ignore that one function surgically. If we ever use libsodium and this
# function in particular in Zeek, should probably revisit this.
race:crypto_secretbox_open_detached
