CI: Fix the ThreadSanitizer build

This commit is contained in:
Tim Wojtulewicz 2022-04-19 10:04:34 -07:00
parent cdadc32985
commit 885ed71464
3 changed files with 53 additions and 12 deletions

View file

@ -355,18 +355,21 @@ ubsan_sanitizer_task:
ZEEK_TAILORED_UB_CHECKS: 1 ZEEK_TAILORED_UB_CHECKS: 1
UBSAN_OPTIONS: print_stacktrace=1 UBSAN_OPTIONS: print_stacktrace=1
# tsan_sanitizer_task: tsan_sanitizer_task:
# container: container:
# # Just uses a recent/common distro to run memory error/leak checks. # Just uses a recent/common distro to run memory error/leak checks.
# dockerfile: ci/ubuntu-20.04/Dockerfile dockerfile: ci/ubuntu-20.04/Dockerfile
# << : *SANITIZERS_RESOURCE_TEMPLATE << : *SANITIZERS_RESOURCE_TEMPLATE
#
# << : *CI_TEMPLATE << : *CI_TEMPLATE
# test_fuzzers_script: ./ci/test-fuzzers.sh << : *SKIP_TASK_ON_PR
# env: env:
# CXXFLAGS: -DZEEK_DICT_DEBUG ZEEK_CI_CONFIGURE_FLAGS: *TSAN_SANITIZER_CONFIG
# ZEEK_CI_CONFIGURE_FLAGS: *TSAN_SANITIZER_CONFIG ZEEK_CI_DISABLE_SCRIPT_PROFILING: 1
# ZEEK_CI_DISABLE_SCRIPT_PROFILING: 1 # If this is defined directly in the environment, configure fails to find
# OpenSSL. Instead we define it with a different name and then give it
# the correct name in the testing scripts.
ZEEK_TSAN_OPTIONS: suppressions=/zeek/ci/tsan_suppressions.txt
windows_task: windows_task:
# 2 hour timeout just for potential of building Docker image taking a while # 2 hour timeout just for potential of building Docker image taking a while

View file

@ -19,6 +19,10 @@ fi
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" &>/dev/null && pwd)" SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" &>/dev/null && pwd)"
. ${SCRIPT_DIR}/common.sh . ${SCRIPT_DIR}/common.sh
if [ -n "${ZEEK_TSAN_OPTIONS}" ]; then
export TSAN_OPTIONS=${ZEEK_TSAN_OPTIONS}
fi
function pushd { function pushd {
command pushd "$@" >/dev/null || exit 1 command pushd "$@" >/dev/null || exit 1
} }

34
ci/tsan_suppressions.txt Normal file
View file

@ -0,0 +1,34 @@
# 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
# 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