[Rcpp-devel] [RcppParallel] Segfault but only on TravisCI
The idea is indeed to avoid copying memory. I thought that doing something like the following would allow me to read the values created in R from within the threads: Rcpp::NumericVector vec(vector_from_R); std::vector<RcppParallel::RVector<double>> series; series.push_back(RcppParallel::RVector<double>(vec)); // then in the threads: double val = series[index_for_this_thread][0]; The data created on the R side is never modified by these functions, just read. It is possible for different threads to read the same memory, but I thought reading was not subject to race conditions. The segfaults are very consistent, every OSX build fails with the same error at the same point. The fact that it happens with clang++ but not with gcc++ is puzzling to me. The Rcpp::List may contain a lot of NumericVector or NumetricMatrix series, so I would rather not copy all of them.
On Sat, Jan 20, 2018 at 2:46 PM, Dirk Eddelbuettel <edd at debian.org> wrote:
On 20 January 2018 at 12:45, Alexis Sarda wrote: | I've found out that the problem remains on OSX builds, and apparently it is | caused by clang itself. I used R-hub's fedora-clang-devel to test: | | https://artifacts.r-hub.io/dtwclust_5.1.0.9000.tar.gz- 6f452fd6aeea4307921df2ab2337e6bb/dtwclust.Rcheck/00check.log | | The error that stands out to me is: | | *** Error in `/opt/R-devel/lib64/R/bin/exec/R': corrupted | double-linked list: 0x00000000099a3870 *** | | | I am essentially doing a parallel distance matrix calculation as shown in | the Rcpp gallery, but I have several distance functions. All the classes | that provide distance calculations have a member wrapping std::vector of | either RcppParallel's RVector<double>, RMatrix<double>, or Armadillo's | cx_vec. Here's the template I'm using to wrap those members: | | https://github.com/asardaes/dtwclust/blob/master/src/utils/TSTSList.h | | Could the corruption be caused by this? It looks to me like you are just moving _actual Rcpp vectors_ around from the Rcpp::List into your container, and then access them using your operator types. But ... that still accesses R memory through these vectors, and with that we may get a (rare ?) race condition on stack unwinding etc. The truly paranoid approach would be to actually make truly distinct types and copy (ie memcpy). That file is short, so maybe you can try it. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20180120/949ba949/attachment.html>