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? Regards, Alexis. On Wed, Jan 17, 2018 at 1:32 PM, Dirk Eddelbuettel <e...@debian.org> wrote: > > On 16 January 2018 at 21:02, Alexis Sarda wrote: > | Hello, > | > | I am integrating RcppParallel into my R package and I'm running into > | strange problems with segmentation faults, but only during the continuous > | integration checks. I have essentially variations of the following (I > hope > | GitHub gist links are ok): > | > | https://gist.github.com/asardaes/7d78af394f848a967997ff23e433c9cf > | > | On TravisCI, my Linux builds simply freeze, and the OSX builds show > | messages like: > | > | *** caught segfault *** > | address 0x100000001, cause 'memory not mapped' > | > | I would assume that my distance functions are trying to access memory > they > | shouldn't, but during interactive use everything works flawlessly, and > I've > | tested all of the following with no problems (which also test > correctness, > | i.e. numeric consistency with respect to past results): > | > | - Local Linux R CMD check > | - Local Windows R CMD check > | - CRAN's WinBuilder check > | - AppVeyor (x32 and x64 Windows) > | - Docker R CMD check using rocker's r-devel-san > | - Local Linux R CMD check with valgrind (no leaks) > | > | It is worth mentioning that some of the examples ran during the OSX build > | show incorrect results long before the segfault occurs: some results are > | zero when they shouldn't be. I don't have access to a machine with OSX, > but > | the Linux builds in TravisCI also show problems (no segfaults explicitly, > | just hangs). > | > | I am at my wit's end. Any input would be appreciated. > > Hard to tell for us, but maybe try the old and trusted route of smaller and > smaller reproducible examples til you reproduce it? > > Or else if it _just_ Travis CI maybe it is a compiler version issue? > Travis > is very conservative in its default setup but there are .travis.yaml > scripts > out there that turn on the PPA for compiler builds giving you gcc-5, gcc-6, > ... amd different clang versions. > > Dirk > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org >
_______________________________________________ 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