Forward progress for both UBSAN and MSAN issues. UBSAN has bifurcated…

… into different suppression files per compiler version (using symlinks for some though).

.github/workflows/main.yml

@@ -313,7 +313,7 @@ jobs:
       # second_deadlock_stack=1 for TSAN: TODO: Explain.  Don't see it in clang TSAN docs.
       before_each_test: |
         export ASAN_OPTIONS="disable_coredump=0"
-        export UBSAN_OPTIONS="disable_coredump=0 print_stacktrace=1 suppressions=${{ github.workspace }}/ubsan_suppressions_${{ matrix.compiler.name }}.cfg"
+        export UBSAN_OPTIONS="disable_coredump=0 print_stacktrace=1 suppressions=${{ github.workspace }}/ubsan_suppressions_${{ matrix.compiler.name }}_${{ matrix.compiler.version }}.cfg"
         export TSAN_OPTIONS="disable_coredump=0 second_deadlock_stack=1 suppressions=${{ github.workspace }}/tsan_suppressions_${{ matrix.compiler.name }}_${{ matrix.compiler.version }}.cfg"
     
     steps: 
@@ -438,7 +438,9 @@ jobs:
         #
         # XXX Other suppressions (cmnt, maybe take sep file?).
         # boost.chrono duration global initializer => std::string uninit value (TODO: too general but...).
-        fun:*_M_is_local*
+        # There is a number of these, including things like operator+() which are tough to specify in
+        # this format; for now going in for a pound, as they say: the entire file.
+        src:*/bit/basic_string.h
         EOF
 
     - name: Install Flow-IPC dependencies with Conan using the profile

ubsan_suppressions_clang_13.cfg

@@ -0,0 +1,2 @@
+# (See higher-version file for explanation.)
+signed-integer-overflow:je_mallocx

ubsan_suppressions_clang_15.cfg

@@ -0,0 +1,12 @@
+# src/jemalloc.c:3133:16: runtime error: left shift of 4095 by 20 places cannot be represented in type 'int'
+# Looks harmless... a macro is doing essentially `((1 << 12) - 1) << 20`, which is a negative int -- used as an & mask.
+# jemalloc should be more civilized IMO, but it is fine.
+shift:je_mallocx
+# tcache.c:144:2: runtime error: variable length array bound evaluates to non-positive value 0
+# Gets invoked from some kind of cleanup hook.  Also look harmless in context, as the actual bound
+# being 0 controls various code touching the "array."  The var-length array is a gcc extension;
+# probably clang too then.
+# jemalloc should really not do this sort of thing though.
+vla-bound:je_tcache_bin_flush_small
+# (Very similar situation; skipping details.)
+vla-bound:je_tcache_bin_flush_large

ubsan_suppressions_clang_16.cfg

@@ -0,0 +1 @@
+ubsan_suppressions_clang_15.cfg

ubsan_suppressions_clang_17.cfg

@@ -0,0 +1 @@
+ubsan_suppressions_clang_16.cfg