(I think I forgot to reply to all) I failed to mention that I am also using RcppArmadillo elsewhere, and I found the following post by the Coatless Professor saying that Armadillo requires at least gcc 4.7.2:
http://thecoatlessprofessor.com/programming/r/selecting-an-a lternative-compiler-for-r-package-testing-on-travis-ci/ However, my Travis builds were already using Trusty (gcc 4.8.4). I think WinBuilder uses gcc 4.9.3, and that one didn't fail. In case it is of interest, I am using Armadillo for exactly one thing: arma::vec cc_seq = arma::real(arma::ifft(fftx % ffty)); and that was also being problematic in Travis (element-wise multiplication due to incompatible dimensions, showing vectors with unreasonably large dimensions). Using version 5 of the compilers as explained in the post above seems to have solved the problems. Thanks, Alexis. On Wed, Jan 17, 2018 at 5:41 PM, Kevin Ushey <kevinus...@gmail.com> wrote: > In your RcppParallel worker, it looks like you're trying to write to > an Rcpp matrix; e.g. you have: > > distmat_(i,j) = local_calculator->calculate(i,j); > > where distmat_ is a matrix. You should avoid using Rcpp classes within > RcppParallel workers, as there's no guarantee that the methods > available on Rcpp classes are thread-safe (and this could lead to > these kinds of segfaults). > > I'll echo Dirk and say that without a minimally reproducible example > (or access to the package source code) there's not much else we can > say. > > You could try running your code with `gctorture(TRUE)` to see if that > triggers your segfault more reliably -- if that's the case, then you > almost surely have an protection issue somewhere (most likely the > result of using non-threadsafe APIs within an RcppParallel worker, but > without full context it's impossible to be sure) > > On Wed, Jan 17, 2018 at 4:32 AM, 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 >
_______________________________________________ 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
