Rcpp: Suppress UBSAN false positives?

Created on 12 Mar 2018  Â·  6Comments  Â·  Source: RcppCore/Rcpp

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?)

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.

All 6 comments

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

karthik2527 picture karthik2527  Â·  4Comments

nettoyoussef picture nettoyoussef  Â·  6Comments

nathan-russell picture nathan-russell  Â·  3Comments

kendonB picture kendonB  Â·  6Comments

krlmlr picture krlmlr  Â·  9Comments