yams/tsan.suppressions
Trevon 72647bbaf7
chore: stabilize CI, faiss, metadata, docker, and simeon (#25)
- CI warm: ccache dep, continue-on-error, 60min timeout, YAMS_DISABLE_FAISS
- Faiss: YAMS_HAS_FAISS guard, Apple Clang disable, OpenMP detection
- Metadata: retry constraint failures, deduplicate batch UPSERT entries
- Docker: wget for Zig, gfortran, YAMS_DISABLE_FAISS=1
- CI config: free-disk-space v1.3.1, libomp-18-dev, experimental trigger
- Weekly benchmarks: faiss disable, ccache, diagnostics capture
- Simeon: bump to 7763a97, EntropyRouter, concept_count
- CorpusStats: extraction readiness fields
- Remove committed artifacts (.wrangler, .artifacts, dispatcher_external)
- Fix .vscode/settings.json hardcoded path

Signed-off-by: trvon <git@trevon.dev>
2026-05-07 21:07:59 -04:00

65 lines
3 KiB
Text

# ThreadSanitizer suppressions for YAMS
# Boost.Asio experimental channel - known library limitation
# The channel_service uses null_mutex even when channel_traits<std::mutex> is specified
# This appears to be a boost library issue in versions < 1.85
race:boost::asio::experimental::detail::channel_service
race:channel_service.hpp
# Boost.Asio thread_info_base - thread-local storage cleanup race
# This is an internal boost::asio issue during thread destruction
race:boost::asio::detail::thread_info_base::deallocate
# Boost.Asio executor - internal race during coroutine dispatch
# This appears to be a timing issue in boost::asio's any_executor
race:boost::asio::execution::detail::any_executor_base::execute
race:any_executor.hpp
# Boost.Asio kqueue reactor descriptor mutex - upstream TSAN false positive when
# conditionally_enabled_mutex is reinitialized out of line with the reactor run
# loop (tracked upstream for Boost.Asio kqueue).
race:boost::asio::detail::conditionally_enabled_mutex
race:boost::asio::detail::conditionally_enabled_mutex::scoped_lock
race:conditionally_enabled_mutex.hpp
race:kqueue_reactor.ipp
race:kqueue_reactor.hpp
race:boost::asio::detail::kqueue_reactor::descriptor_state
race:boost::asio::detail::kqueue_reactor::allocate_descriptor_state
race:boost::asio::detail::kqueue_reactor::register_descriptor
race:boost::asio::detail::kqueue_reactor::run
race:object_pool.hpp
# Boost.Asio reactive socket service - race in socket descriptor registration
# when sockets are constructed/moved across threads. The reactor's internal
# fd_set_ tracking has a data race in reactive_socket_service_base::construct().
# This is a known boost::asio internal issue.
race:boost::asio::detail::reactive_socket_service_base::construct
race:boost::asio::detail::reactive_socket_service_base::do_assign
race:reactive_socket_service_base.ipp
race:reactive_socket_accept_op.hpp
# Boost.Asio strand destructor - mutex use-after-free during complex shutdown
# When ServiceManager is destroyed, pending async operations may still hold
# references to the strand's executor. This is a destruction order issue
# in complex coroutine-based shutdown sequences.
mutex:boost::asio::strand
mutex:boost::asio::detail::posix_mutex
mutex:boost::asio::detail::strand_executor_service
race:TuningManager
race:unique_ptr*TuningManager
# tinyfsm uses CRTP static state per Fsm class, so concurrent construction
# of multiple YamsDaemon instances in the same process (test-only scenario)
# races on the static snapshot/entry storage. Production has one daemon
# per process; the race cannot occur there.
race:yams::daemon::detail::LifecycleMachine
race:yams::daemon::detail::PluginHostMachine
race:yams::daemon::detail::EmbeddingProviderMachine
race:yams::daemon::detail::SearchEngineMachine
race:yams::daemon::detail::ServiceManagerMachine
race:yams::daemon::LifecycleSnapshot
race:yams::daemon::ProviderSnapshot
race:yams::daemon::PluginHostSnapshot
race:yams::daemon::SearchEngineSnapshot
race:yams::daemon::ServiceManagerSnapshot