Hello, I use Rcpp in the package I maintain, MatchIt. I recently upload it to CRAN with no problems, but then received a message saying there were "additional issues" I needed to address, which were titled clang-ASAN and gcc-ASAN. Looking at the log, it seems that the error was triggered when I used an R function (mahalanobis()) inside the Rcpp code. I realized that I had not properly initialized the function in my Rcpp script. Although the package functions ran correctly, perhaps something about the way the memory was allocated caused this issue. I think I fixed the issue, but I want to check it without uploading it to CRAN again. This issue was not picked up by R cmd check or by the check in winbuilder, so I'm not sure how to check if I have solved the issue. CRAN even accepted my package before letting me know about this issue.
In searching for solutions to the problem of being able to check whether the issue in my package remains, I came across this <http://dirk.eddelbuettel.com/code/sanitizers.html> article posted by Dirk ("sanitizers: Testing R packages for ASAN and UBSAN errors"). It seems like this article is about using sanitizers, which helps you figure out if your build of R is able to detect the memory allocation errors I was facing, but doesn't give clear instructions on how to set up R to do this. As someone for whom using Rcpp was my first use of programming outside R, the instructions given in the article and in section 4.3 of Writing R Extensions are completely foreign to me and seem to require a deep knowledge of C++. I'm wondering if someone can provide me with a clear procedure on how to check if the memory allocation problem still remains in my package. Thank you. Noah Greifer PS What seems to be the relevant text in the error message is pasted below: ==1503820==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffc220ca7a0 at pc 0x7fc2fb4668ad bp 0x7ffc220ca5b0 sp 0x7ffc220ca5a8 READ of size 8 at 0x7ffc220ca7a0 thread T0 #0 0x7fc2fb4668ac in Rcpp::PreserveStorage<Rcpp::Vector<14, Rcpp::PreserveStorage> >::get__() const /data/gannet/ripley/R/test-clang/Rcpp/include/Rcpp/storage/PreserveStorage.h:26:20 #1 0x7fc2fb4668ac in Rcpp::Vector<14, Rcpp::PreserveStorage>::size() const /data/gannet/ripley/R/test-clang/Rcpp/include/Rcpp/vector/Vector.h:277:39 #2 0x7fc2fb4668ac in Rcpp::sugar::Vectorized<&(sqrt), true, Rcpp::Vector<14, Rcpp::PreserveStorage> >::size() const /data/gannet/ripley/R/test-clang/Rcpp/include/Rcpp/sugar/block/Vectorized_Math.h:40:50 ... Address 0x7ffc220ca7a0 is located in stack of thread T0 at offset 448 in frame #0 0x7fc2fb46644f in void Rcpp::Vector<14, Rcpp::PreserveStorage>::assign_sugar_expression<Rcpp::sugar::Vectorized<&(sqrt), true, Rcpp::Vector<14, Rcpp::PreserveStorage> > >(Rcpp::sugar::Vectorized<&(sqrt), true, Rcpp::Vector<14, Rcpp::PreserveStorage> > const&) /data/gannet/ripley/R/test-clang/Rcpp/include/Rcpp/vector/Vector.h:1038 This frame has 1 object(s): [32, 48) 'ref.tmp.i.i.i.i.i' <== Memory access at offset 448 overflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-use-after-scope /data/gannet/ripley/R/test-clang/Rcpp/include/Rcpp/storage/PreserveStorage.h:26:20 in Rcpp::PreserveStorage<Rcpp::Vector<14, Rcpp::PreserveStorage> >::get__() const Shadow bytes around the buggy address: 0x1000044114a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
_______________________________________________ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
