CRAN reports some UBSAN warnings while building Rcpp (https://www.stats.ox.ac.uk/pub/bdr/memtests/clang-UBSAN/Rcpp/build_vignettes.log):
/data/gannet/ripley/R/packages/tests-clang-SAN/Rcpp.Rcheck/Rcpp/include/Rcpp/routines.h:80:20: runtime error: call to function Rcpp::internal::enterRNGScope() through pointer to incorrect function type 'unsigned long (*)()'
/data/gannet/ripley/R/packages/tests-clang-SAN/Rcpp/src/api.cpp:72: note: Rcpp::internal::enterRNGScope() defined here
This has come up on mailing lists a couple times, e.g.
http://lists.r-forge.r-project.org/pipermail/rcpp-devel/2017-July/009656.html
This appears to be a false positive from UBSAN:
https://github.com/google/sanitizers/issues/911
We might be able to work around this by explicitly disabling the function sanitizer for these functions, as per https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html:
You disable UBSan checks for particular functions with
__attribute__((no_sanitize("undefined"))). You can use all values of
-fsanitize= flag in this attribute, e.g. if your function deliberately contains
possible signed integer overflow, you can use
__attribute__((no_sanitize("signed-integer-overflow"))).
We might also want to let CRAN know that the UBSAN function sanitizer is buggy. (Maybe they already know and would rather live with false positives if it means capturing some true bugs, though?)
I like your thinking here but would _explicitly disabling_ not clearly run afoul of the somewhat recently added CRAN policy insisting that nobody messes with compiler diagnostics?
Which coincidentally is the same point Joe made in the r-lib ticket.
Good point. Perhaps nothing to do here then but at least we have this documented in case anyone else brings up these UBSAN warnings.
@kevinushey Just in time ;-)
For a dplyr run, I was able to mute these false positives by creating a file UBsan.supp with the following contents
function:Rcpp/routines.h
function:include/*_RcppExports.h
function:test.cpp
and invoking R with
UBSAN_OPTIONS=suppressions=$PWD/UBsan.upp R ...
. Other packages will need other suppressions, but the first two seem to be of generic use.
Reference: https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#id11
Very interesting. But we do not control how Brian Ripley invokes his tests so we cannot whitelist at CRAN, which is how this started.
Most helpful comment
Good point. Perhaps nothing to do here then but at least we have this documented in case anyone else brings up these UBSAN warnings.