Found while verifying PR #673, whose #668 work needed to prove a TSan build was actually instrumented before trusting a test result from it. Filed rather than left in a hand-back.
The finding
scripts/check_sanitizer_instrumentation.sh refuses to report on a build tree containing one binary:
only examined 1 binaries -- too few for this check to mean anything
That guard is correct in intent — a sweep that examined nothing must not report success, which is this repository's most-filed defect class. But it makes the script unusable for the case where its answer matters most: a developer building a single target under a sanitizer preset to check one hypothesis, who wants to know the binary carries __tsan_ before believing what it printed.
The #673 lane hit exactly that and had to fall back to counting __tsan_ symbols by hand (173 in its binary). That works, and it is the kind of ad-hoc substitute a gate exists to make unnecessary.
Verification status: reproduced by another session, read from the code by me
I confirmed the guard exists and its message. I did not build a single-target sanitizer tree to see it fire; that observation is the #673 lane's, in its hand-back.
Why the guard's shape is the problem, not the guard
The floor conflates two different questions:
- "Did this check examine a representative set?" — which is what a floor answers, and what a CI invocation needs.
- "Is this specific binary instrumented?" — which is a yes/no about one file, and needs no floor at all.
A single-binary tree is a legitimate answer to the second and a failure of the first. The script currently only offers the first.
What would resolve it
Probably an explicit narrow mode — a flag naming one binary, which answers the second question and skips the floor — leaving the default behaviour and its floor exactly as they are. The important constraint is that the narrow mode must not become a way to satisfy the CI invocation: if it can be passed where the floor was meant to apply, the floor is gone.
Alternatively, lower the floor only when the tree genuinely contains one target rather than when the scan found one — those differ, and the distinction is the whole safety of the change.
What would change the verdict
Close as wontfix if the narrow case is better served by a documented nm | grep __tsan_ one-liner than by another mode in the script. That is a reasonable answer, and writing the one-liner where someone will find it would close this.
Related
🤖 Generated with Claude Code
https://claude.ai/code/session_01VptDWG2fKr2vBnLSJcgzgW
Found while verifying PR #673, whose #668 work needed to prove a TSan build was actually instrumented before trusting a test result from it. Filed rather than left in a hand-back.
The finding
scripts/check_sanitizer_instrumentation.shrefuses to report on a build tree containing one binary:That guard is correct in intent — a sweep that examined nothing must not report success, which is this repository's most-filed defect class. But it makes the script unusable for the case where its answer matters most: a developer building a single target under a sanitizer preset to check one hypothesis, who wants to know the binary carries
__tsan_before believing what it printed.The #673 lane hit exactly that and had to fall back to counting
__tsan_symbols by hand (173 in its binary). That works, and it is the kind of ad-hoc substitute a gate exists to make unnecessary.Verification status: reproduced by another session, read from the code by me
I confirmed the guard exists and its message. I did not build a single-target sanitizer tree to see it fire; that observation is the #673 lane's, in its hand-back.
Why the guard's shape is the problem, not the guard
The floor conflates two different questions:
A single-binary tree is a legitimate answer to the second and a failure of the first. The script currently only offers the first.
What would resolve it
Probably an explicit narrow mode — a flag naming one binary, which answers the second question and skips the floor — leaving the default behaviour and its floor exactly as they are. The important constraint is that the narrow mode must not become a way to satisfy the CI invocation: if it can be passed where the floor was meant to apply, the floor is gone.
Alternatively, lower the floor only when the tree genuinely contains one target rather than when the scan found one — those differ, and the distinction is the whole safety of the change.
What would change the verdict
Close as
wontfixif the narrow case is better served by a documentednm | grep __tsan_one-liner than by another mode in the script. That is a reasonable answer, and writing the one-liner where someone will find it would close this.Related
🤖 Generated with Claude Code
https://claude.ai/code/session_01VptDWG2fKr2vBnLSJcgzgW