valgrind/helgrind: suppress libstdc++ _Sp_locker atomic<shared_ptr> FP

Run 29304424198 (3d6cf0b) drove helgrind from 168 residual errors down to a
single one, and confirmed drd fully green (the MHD poll-listen `...` +
MHD_queue_response frames landed). The lone remaining helgrind report is a
libstdc++ atomic-shared-ptr false positive, not a libhttpserver locking race:

  Possible data race during read of size 8 ...
    std::_Sp_locker::_Sp_locker
    std::atomic_load_explicit<resource_hook_table>(shared_ptr*)
    httpserver::ensure_table (http_resource.cpp:96)
    httpserver::http_resource::add_hook (http_resource.cpp:214)

ensure_table() uses the correct lock-free idiom — atomic_load_explicit(acquire)
plus atomic_compare_exchange_strong_explicit(acq_rel) — so every concurrent
access to hook_table_ goes through the std::atomic_* free functions. libstdc++
implements those with an internal _Sp_locker spinlock whose happens-before
Helgrind cannot model (same blind spot as the _Sp_counted_base::_M_release entry
already suppressed). TSan, which models the atomics precisely, is green on this
same test — corroborating it is a detector artifact. Matched on the third-party
_Sp_locker frame (never the libhttpserver caller): a genuinely unsynchronised
shared_ptr access would surface a non-_Sp_locker frame and stay unsuppressed, so
DR-008 is preserved. Mirrored into the drd supp for symmetry/future-proofing
(drd did not flag it this run).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NpysYDDJac63yz2mZKKiDf

Author: etr

test/valgrind-drd.supp

@@ -82,6 +82,21 @@
    fun:*_Sp_counted_base*_M_release*
 }
 
+# --- libstdc++ atomic<shared_ptr> free-function ops (_Sp_locker spinlock) -----
+# std::atomic_load/atomic_compare_exchange on a std::shared_ptr take a
+# libstdc++-internal _Sp_locker spinlock whose happens-before DRD does not model,
+# so it can report a benign conflict between two correctly-synchronised atomic
+# accesses to the SAME shared_ptr (http_resource::hook_table_, via ensure_table's
+# atomic_load/compare_exchange lock-free idiom). Helgrind reports the mirror of
+# this; kept here in sync. Matched on the third-party _Sp_locker frame, never the
+# libhttpserver caller, so DR-008 is unaffected.
+{
+   libstdcxx-atomic-shared-ptr-sp-locker
+   drd:ConflictingAccess
+   ...
+   fun:*_Sp_locker*
+}
+
 # --- benign lock-free reads of immutable-after-registration resource config -
 # Written once at registration (before start()), only READ from the MHD worker
 # during dispatch. NOT a libhttpserver locking race (DR-008).

test/valgrind-helgrind.supp

@@ -79,6 +79,26 @@
    fun:*_Sp_counted_base*_M_release*
 }
 
+# --- libstdc++ atomic<shared_ptr> free-function ops (_Sp_locker spinlock) -----
+# std::atomic_load/atomic_compare_exchange on a std::shared_ptr take a
+# libstdc++-internal _Sp_locker spinlock (global pool) to make the pointer +
+# control-block update atomic. Helgrind does not model that spinlock's
+# happens-before, so it reports a benign race between two correctly-synchronised
+# atomic accesses to the SAME shared_ptr -- here http_resource::hook_table_,
+# driven by ensure_table()'s atomic_load(acquire)/compare_exchange(acq_rel)
+# lock-free idiom when a handler calls add_hook() concurrently on multiple MHD
+# workers. Same detector blind spot as _Sp_counted_base::_M_release above; TSan,
+# which models the atomics precisely, reports NO race on this test. Matched on
+# the libstdc++ _Sp_locker frame (third-party) -- a genuinely unsynchronised
+# shared_ptr access would surface its own (non-_Sp_locker) frame and stay
+# unsuppressed, so DR-008 (libhttpserver's own locking) is unaffected.
+{
+   libstdcxx-atomic-shared-ptr-sp-locker
+   Helgrind:Race
+   ...
+   fun:*_Sp_locker*
+}
+
 # --- benign lock-free reads of immutable-after-registration resource config -
 # The method-dispatch table and a resource's allowed-method set are written
 # once at registration (before start()) and only READ from the MHD worker