[Rcpp-devel] [RcppParallel] Segfault but only on TravisCI

[Alexis Sarda]

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>