Add sanitizer support via score_cpp_policies

[VukPavicRTRK]

Description

Integrates ASan, UBSan, LSan, and TSan using the centralized score_cpp_policies infrastructure rather than a self-contained implementation, avoiding fragmentation across S-CORE modules.

Changes

MODULE.bazel - adds score_cpp_policies as a dev_dependency via git_override (not yet in the bazel_registry).

.bazelrc - adds sanitizer configs backed by score_cpp_policies' runtime infrastructure (wrapper script, suppression files, env templates):

• --config=asan_ubsan_lsan - AddressSanitizer + UBSan + LeakSanitizer
• --config=tsan - ThreadSanitizer (separate run, incompatible with ASan)
• --config=asan / --config=ubsan / --config=lsan - convenience aliases
• Tag filters (-no-asan, -no-tsan, etc.) are baked into each config

Note: flags are applied via --copt/--linkopt directly rather than --features=score_asan_ubsan_lsan, because score_bazel_cpp_toolchains does not yet expose the cc_feature targets from score_cpp_policies. The wrapper, suppression files, and flag infrastructure from score_cpp_policies are fully used.

.github/workflows/sanitizers.yml - CI job running both configs against //src/... //tests/... on every PR, merge group, and push to main. The TSan job sets kernel.randomize_va_space=0 to satisfy TSan's shadow memory layout requirements in the GitHub Actions runner.

src/launch_manager_daemon/common/concurrency/BUILD - removes mpmc_concurrent_queue_tsan_test, which had hardcoded -fsanitize=thread copts/linkopts. Those flags would double-instrument the binary when running under --config=tsan. The regular mpmc_concurrent_queue_test now covers TSan via the global config.

Running locally

ASan + UBSan + LSan

bazel test --config=asan_ubsan_lsan --config=x86_64-linux //src/... //tests/...

ThreadSanitizer

Note: requires ASLR to be in conservative mode.
In a standard Linux environment:

sudo sysctl -w kernel.randomize_va_space=0
bazel test --config=tsan --config=x86_64-linux //src/... //tests/...

Closes #50

[github-actions]

License Check Results

🚀 The license check job ran with the Bazel command:

bazel run --lockfile_mode=error //:license-check

Status: ⚠️ Needs Review

Click to expand output

[License Check Output]
Extracting Bazel installation...
Starting local Bazel server (8.4.2) and connecting to it...
INFO: Invocation ID: 7e496873-37ab-4fae-9a58-a951f592090f
Computing main repo mapping: 
Computing main repo mapping: 
Loading: 
Loading: 0 packages loaded
Loading: 0 packages loaded
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Analyzing: target //:license-check (1 packages loaded, 0 targets configured)
Analyzing: target //:license-check (1 packages loaded, 0 targets configured)

Analyzing: target //:license-check (32 packages loaded, 10 targets configured)

Analyzing: target //:license-check (84 packages loaded, 10 targets configured)

Analyzing: target //:license-check (125 packages loaded, 654 targets configured)

Analyzing: target //:license-check (144 packages loaded, 5360 targets configured)

Analyzing: target //:license-check (154 packages loaded, 5429 targets configured)

Analyzing: target //:license-check (154 packages loaded, 5429 targets configured)

Analyzing: target //:license-check (160 packages loaded, 10098 targets configured)

Analyzing: target //:license-check (161 packages loaded, 10106 targets configured)

INFO: Analyzed target //:license-check (162 packages loaded, 10232 targets configured).
[7 / 16] Creating runfiles tree bazel-out/k8-opt-exec-ST-d57f47055a04/bin/external/score_tooling+/dash/tool/formatters/dash_format_converter.runfiles [for tool]; 0s local
[13 / 16] JavaToolchainCompileClasses external/rules_java+/toolchains/platformclasspath_classes; 0s disk-cache, processwrapper-sandbox
[14 / 16] JavaToolchainCompileBootClasspath external/rules_java+/toolchains/platformclasspath.jar; 0s disk-cache, processwrapper-sandbox
INFO: Found 1 target...
Target //:license.check.license_check up-to-date:
  bazel-bin/license.check.license_check
  bazel-bin/license.check.license_check.jar
INFO: Elapsed time: 23.429s, Critical Path: 2.49s
INFO: 16 processes: 12 internal, 3 processwrapper-sandbox, 1 worker.
INFO: Build completed successfully, 16 total actions
INFO: Running command line: bazel-bin/license.check.license_check ./formatted.txt <args omitted>
usage: org.eclipse.dash.licenses.cli.Main [-batch <int>] [-cd <url>]
       [-confidence <int>] [-ef <url>] [-excludeSources <sources>] [-help] [-lic
       <url>] [-project <shortname>] [-repo <url>] [-review] [-summary <file>]
       [-timeout <seconds>] [-token <token>]

[github-actions]

The created documentation from the pull request is available at: docu-html

[FScholPer]

be aware there is also going work in that direction in score_cpp_policies repo

[VukPavicRTRK]

be aware there is also going work in that direction in score_cpp_policies repo

Should lifecycle continue with the self-contained sanitizer implementation in this PR as a short-term unblocker, planning a later migration to the shared score_cpp_policies module once its sanitizer structure stabilizes or do we want to pivot now and integrate directly with the centralized sanitizer infrastructure despite the potential dependency and release-readiness risks?

[FScholPer]

My opinion: I would say we should bring in our thoughts into score_cpp_policies and not create silos. @NicolasFussberger @S-MOHAMD @pawelrutkaq any thoughts on this?

[NicolasFussberger]

My opinion: I would say we should bring in our thoughts into score_cpp_policies and not create silos. @NicolasFussberger @S-MOHAMD @pawelrutkaq any thoughts on this?

If we can bring in these changes into score_cpp_policies, I agree that this should be the preferred solution. I cannot judge how realistic this is.