# ThreadSanitizer suppressions for wxMaxima.
#
# These silence data races that live entirely inside third-party libraries we
# only call into (the GTK / GLib image + font stack). They are NOT wxMaxima
# bugs and cannot be fixed here; without suppressing them a TSan run drowns in
# hundreds of reports (mostly from the glycin image loader decoding the toolbar
# and status-bar SVG icons in its own sandboxed threads) and crawls.
#
# Usage:
#   TSAN_OPTIONS="suppressions=$PWD/test/tsan_suppressions.supp" \
#     xvfb-run -a ctest --test-dir build-tsan -R multithreadtest
#
# If TSan ever reports a race whose frames are in wxMaxima's own src/, that is a
# real finding and must NOT be added here.

# glycin: GNOME image loader; decodes images in sandboxed worker threads.
called_from_lib:libglycin-2.so.0
race:libglycin

# GLib / GObject / GIO: type system, GMainContext, async I/O internals.
race:libglib-2.0
race:libgobject-2.0
race:libgio-2.0

# GDK / GTK widget toolkit internals.
race:libgdk-3
race:libgtk-3

# Font / text stack caches.
race:libfontconfig
race:libpango
race:libpangoft2
race:libpangocairo
race:libcairo

# harfbuzz / freetype shaping + glyph caches.
race:libharfbuzz
race:libfreetype

# --- Lock-order-inversion ("potential deadlock") false positives ---
#
# These are not data races but cross-thread lock-ordering reports. Every one of
# them runs through GLib's one-time type-system / reader-writer locks
# (g_rw_lock_*, g_type_class_get) that the main thread holds while it builds the
# toolbar / status-bar icons at start-up (StatusBar::UpdateBitmaps). That GLib
# leg crosses with wxWidgets' own mutexes (wxMutex), which are taken later and
# from other threads - the image-loading workers and the Maxima reader thread -
# so TSan synthesises a lock cycle. The GLib leg is only ever held once, during
# init, so the cycle can never actually close at run time.
#
# wxMaxima's own std::mutex locking (BackgroundQueue / BackgroundTask, the
# Maxima queues) does NOT appear in any of these cycles; only the third-party
# GLib lock primitives do. If TSan ever reports a deadlock cycle made up solely
# of wxMaxima's own mutexes, that is a real finding and must NOT be added here.
deadlock:g_rw_lock_reader_lock
deadlock:g_rw_lock_writer_lock
deadlock:g_type_class_get
# The matching "read lock of a write locked mutex" report on the same GLib lock.
mutex:g_rw_lock_reader_lock
