ASAN issue with Rcpp 0.12.8 under gcc-7

[eddelbuettel]

Via email:

Quite a lot of errors in other packages are showing up with this Rcpp
version, only on Linux and only with a default build (not with
--enable-Rshlib). A possibly incomplete list is

BEDMatrix biwavelet chopthin dplyr feather geohash h5 icd lfl plyr
purrr rags2ridges readr rmumps rucrdtw svglite tidyr validatejsonr
wrswoR xml2

where the pattern seems to be that C++ error messages via e.g. 'stop'
are reported incorrectly. See the fedora-{gcc,clang} CRAN logs but many
of these use testthat to completely obfuscate the error: BEDmatrix and
xml2 are typical for the one error they do show.

This is possibly related to many stack-use-after-scope ASAN errors
showing with gcc trunk (e.g.
http://www.stats.ox.ac.uk/pub/bdr/memtests/gcc7-ASAN/BWStest/ contains

==6559==ERROR: AddressSanitizer: stack-use-after-scope on address 
0x7ffd186b08e0 at pc 0x7f14dc17f552 bp 0x7ffd186b0470 sp 0x7ffd186afc20
READ of size 17 at 0x7ffd186b08e0 thread T0
     #0 0x7f14dc17f551  (/usr/local/gcc7/lib64/libasan.so.4+0x64551)
     #1 0x7f14d87284b1 
(/usr/local/gcc7/lib/../lib64/libstdc++.so.6+0x924b1)
     #2 0x7f14d8731724 
(/usr/local/gcc7/lib/../lib64/libstdc++.so.6+0x9b724)
     #3 0x7f14d8731879 in __cxa_demangle 
(/usr/local/gcc7/lib/../lib64/libstdc++.so.6+0x9b879)
     #4 0x7f14cb7808bc in demangle(std::__cxx11::basic_string<char, 
std::char_traits<char>, std::allocator<char> > const&) 
/tmp/RtmpJHuBqT/R.INSTALL9f9c58a482ce/Rcpp/src/api.cpp:125
     #5 0x7f14cb125779 in demangle(std::__cxx11::basic_string<char, 
std::char_traits<char>, std::allocator<char> > const&) 
/data/gannet/ripley/R/test-3.4/Rcpp/include/Rcpp/routines.h:137
     #6 0x7f14cb125779 in exception_to_r_condition(std::exception 
const&) /data/gannet/ripley/R/test-3.4/Rcpp/include/Rcpp/exceptions.h:212
     #7 0x7f14cb11eacb in BWStest_murakami_stat_perms 
/data/gannet/ripley/R/packages/tests-70/BWStest/src/RcppExports.cpp:57

), all involving exception_to_r_condition . Also within the last week,
but gcc trunk is a moving target.

I disagree a little on what a default build is -- to me with shared library is far more common (or else both littler and RInside would fail to build) but the ASAN errors are something we should look into.

First step is probably to see what they do on under our ASAN tools (ie Docker), maybe R Hub too.

[kevinushey]

This is the line of code that appears to be triggering the ASAN warning: (

Rcpp/src/api.cpp

Line 125 in 327d057

dem = abi::__cxa_demangle(name.c_str(), 0, 0, &status);

):

dem = abi::__cxa_demangle(name.c_str(), 0, 0, &status);

With documentation here: https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-4.3/a01696.html

It's possible that we're not extracting the mangled name correctly here, and that's causing downstream issues:

Rcpp/src/api.cpp

Lines 41 to 49 in 327d057

	static std::string demangler_one(const char* input) {
	static std::string buffer;
	buffer = input;
	buffer.resize(buffer.find_last_of('+') - 1);
	buffer.erase(
	buffer.begin(),
	buffer.begin() + buffer.find_last_of(' ') + 1
	);
	return demangle(buffer);

Rcpp/src/api.cpp

Lines 273 to 295 in 327d057

	#else // ! (defined(_WIN32) || defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__) || defined(__CYGWIN__) || defined(__sun) || defined(_AIX)
	/* inspired from http://tombarta.wordpress.com/2008/08/01/c-stack-traces-with-gcc/ */
	const size_t max_depth = 100;
	int stack_depth;
	void *stack_addrs[max_depth];
	char **stack_strings;
	stack_depth = backtrace(stack_addrs, max_depth);
	stack_strings = backtrace_symbols(stack_addrs, stack_depth);
	std::string current_line;
	CharacterVector res(stack_depth - 1);
	std::transform(stack_strings + 1, stack_strings + stack_depth, res.begin(), demangler_one);
	free(stack_strings); // malloc()ed by backtrace_symbols
	List trace = List::create(_["file" ] = file,
	_["line" ] = line,
	_["stack"] = res);
	trace.attr("class") = "Rcpp_stack_trace";
	return trace;
	#endif

I wonder if it's possible that backtrace and backtrace_symbols are slightly different in gcc-7?

[eddelbuettel]

Nice work. Fast way to get hold off gcc-7 may be a Docker container with Debian unstable (maybe testing) and add the experimental repo: https://packages.debian.org/experimental/gcc-7

[eddelbuettel]

Via email, after I offered the current master as 0.12.8.1:

Dirk,

1. This solves the misreporting of error messsages from Rcpp::stop etc, so
   would be good to have on CRAN. I will use it for my Fedora checks as from
   today.

2. It seems it was gcc trunk which changed. Both gcc and clang trunk
   document a new flag -fsanitize-address-use-after-scope but although documented
   as separate from -fsanitize=address, in gcc trunk it is silently implied by
   the latter. (I reinstalled Rcpp 0.12.7 and got essentially the same ASAN
   traceback.)

It is not mentioned in gcc7's libsanitizer/ChangeLog.

So current gcc7's ASAN thinks something is wrong, but until you have a chance
to look at it, I will add -fno-sanitize-address-use-after-scope in CXX[1X] for
gcc7.

The only other instances I see are in RSQLite (in its C code) and in C++ code
in haven.

[eddelbuettel]

There does not appear to be an open ASAN issue against us. There is one from vignettes but that is just compiler pickyness over things we need to do and for which we are grandfathered.