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

[Alexis Sarda]

After testing locally with clang, it seems the problem actually was that
there were different classes inheriting from RcppParallel::Worker in
different cpp files, but they all had the same names and the same
constructors, yet different logic. There were no compilation warnings, but
apparently clang doesn't isolate each class to the file where it is
declared+defined, even if it doesn't appear in any header.

Thanks,
Alexis.


On Sat, Jan 20, 2018 at 4:22 PM, Dirk Eddelbuettel <edd at debian.org> wrote:

>
> On 20 January 2018 at 15:05, Alexis Sarda wrote:
> | 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.
>
> But the RcppParallel documentation is pretty clear on "do not touch R
> memory
> from multiple threads".
>
> 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/7cca95a2/attachment.html>