Part of the sweep tracked in #518. Finding F23.
Summary
Two independent facts combine so that live UB in include/morph merges with a green matrix.
cmake/compiler_options.cmake:476-493 never passes -fno-sanitize-recover. grep -rn "sanitize-recover\|sanitize-trap" returns nothing in the repo. UBSan's default is recover: print a diagnostic, continue, exit 0.
- The
linux-sanitizers job (.github/workflows/ci.yml:308-414) sets only TSAN_OPTIONS (:400). grep -rn "UBSAN_OPTIONS\|ASAN_OPTIONS" across the entire repo returns exactly two lines — ci.yml:1397-1398 — both in the ladder job.
Verification status
Inferred from reading the build and workflow configuration; not reproduced. Revision: master @ 4017228d. I did not push a commit with deliberate UB to watch the matrix stay green. The two greps are exact, and UBSan's recover-by-default behaviour is documented upstream.
This is how F19 (INT64_MIN UB in Rational) survived: it fires under UBSan, and UBSan cannot fail the build.
Suggested fix
Fix it at the source rather than per-job — it then survives someone dropping an env var from a workflow:
# in apply_sanitizers(), asan and ubsan arms
-fno-sanitize-recover=undefined
The repo already has the correct incantation for the env-var route (ci.yml:1398: UBSAN_OPTIONS: print_stacktrace=1:halt_on_error=1); it is simply not applied to the framework's own suite.
Related, same function
apply_sanitizers() is if asan / elseif tsan / elseif ubsan / endif with no else() and no FATAL_ERROR. -DAF_SANITIZER=msan, =ASAN, or a typo produces a fully uninstrumented build that configures, builds and runs the whole suite green. The repo already knows this class of bug — ci.yml:1360-1386 adds an nm -C | grep __asan_ assertion for exactly this reason, for the ladder only.
What would change the verdict
- Close it if UBSan is deliberately advisory here — but then the
clang-ubsan leg is a linting pass, not a gate, and should say so.
- The check that this fix is real: land F19's regression test after this change and confirm the leg goes red without the
Rational fix. Per AGENTS.md, a control that reports success while measuring nothing is the failure mode this repo has hit most often; this is one.
Part of the sweep tracked in #518. Finding F23.
Summary
Two independent facts combine so that live UB in
include/morphmerges with a green matrix.cmake/compiler_options.cmake:476-493never passes-fno-sanitize-recover.grep -rn "sanitize-recover\|sanitize-trap"returns nothing in the repo. UBSan's default is recover: print a diagnostic, continue, exit 0.linux-sanitizersjob (.github/workflows/ci.yml:308-414) sets onlyTSAN_OPTIONS(:400).grep -rn "UBSAN_OPTIONS\|ASAN_OPTIONS"across the entire repo returns exactly two lines —ci.yml:1397-1398— both in the ladder job.Verification status
Inferred from reading the build and workflow configuration; not reproduced. Revision:
master@4017228d. I did not push a commit with deliberate UB to watch the matrix stay green. The two greps are exact, and UBSan's recover-by-default behaviour is documented upstream.This is how F19 (
INT64_MINUB inRational) survived: it fires under UBSan, and UBSan cannot fail the build.Suggested fix
Fix it at the source rather than per-job — it then survives someone dropping an env var from a workflow:
The repo already has the correct incantation for the env-var route (
ci.yml:1398:UBSAN_OPTIONS: print_stacktrace=1:halt_on_error=1); it is simply not applied to the framework's own suite.Related, same function
apply_sanitizers()isif asan / elseif tsan / elseif ubsan / endifwith noelse()and noFATAL_ERROR.-DAF_SANITIZER=msan,=ASAN, or a typo produces a fully uninstrumented build that configures, builds and runs the whole suite green. The repo already knows this class of bug —ci.yml:1360-1386adds annm -C | grep __asan_assertion for exactly this reason, for the ladder only.What would change the verdict
clang-ubsanleg is a linting pass, not a gate, and should say so.Rationalfix. PerAGENTS.md, a control that reports success while measuring nothing is the failure mode this repo has hit most often; this is one.