The gcc-ASAN / AddressSanitizer tests job has been failing on every
branch since test-Concordance.R:433 landed:
Error ('test-Concordance.R:433:3'): Concordance functions document NaN for
uninformative pairs (#110)
Error in `tools::Rd_db("TreeSearch")`: installed help of package
'TreeSearch' is corrupt
Seen on 31193721419
(feature/consistency-fixes) and
31210334799
(feature/ub-class-audit), on branches that touch neither Rd files nor
roxygen. Both runs are otherwise clean: [ FAIL 1 | WARN 0 | SKIP 18 ],
and the one failure is this.
Cause
The r-hub gcc-asan container installs the package without building a help
database, so tools::Rd_db() has nothing to read. The test asserts against
how the local environment happens to be installed, not against anything
the package promises — the same trap as
.AGENTS/memory/'s "a test can pass for the wrong reason" note, in the
mirror-image direction: here it fails for the wrong reason.
Why it matters more than one red check
gcc-ASAN is the only leg that runs UBSan, and UBSan is the only
detector for one half of the degenerate-container UB class — a null
.data() reaching a nonnull parameter is invisible to hardened
libstdc++ and to plain builds (see #177). A permanently-red ASan leg
trains readers to skim past it, which is how that class went unwatched
before.
Suggested fix
Skip the docstring check when no help database is installed, rather than
asserting one exists:
skip_if(length(tools::Rd_db("TreeSearch")) == 0, "No installed help database")wrapped so the error itself is caught, or gate the whole test on
skip_on_cran() plus a requireNamespace-style guard for the Rd db.
Reopening condition
Any ASan run whose only failure is an environment assumption rather than a
sanitizer report.
The
gcc-ASAN/AddressSanitizer testsjob has been failing on everybranch since
test-Concordance.R:433landed:Seen on 31193721419
(
feature/consistency-fixes) and31210334799
(
feature/ub-class-audit), on branches that touch neither Rd files norroxygen. Both runs are otherwise clean:
[ FAIL 1 | WARN 0 | SKIP 18 ],and the one failure is this.
Cause
The r-hub gcc-asan container installs the package without building a help
database, so
tools::Rd_db()has nothing to read. The test asserts againsthow the local environment happens to be installed, not against anything
the package promises — the same trap as
.AGENTS/memory/'s "a test can pass for the wrong reason" note, in themirror-image direction: here it fails for the wrong reason.
Why it matters more than one red check
gcc-ASANis the only leg that runs UBSan, and UBSan is the onlydetector for one half of the degenerate-container UB class — a null
.data()reaching anonnullparameter is invisible to hardenedlibstdc++ and to plain builds (see #177). A permanently-red ASan leg
trains readers to skim past it, which is how that class went unwatched
before.
Suggested fix
Skip the docstring check when no help database is installed, rather than
asserting one exists:
wrapped so the error itself is caught, or gate the whole test on
skip_on_cran()plus arequireNamespace-style guard for the Rd db.Reopening condition
Any ASan run whose only failure is an environment assumption rather than a
sanitizer report.