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

[Alexis Sarda]

(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 <kevinushey at 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 <edd at 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 | edd at debian.org
> > _______________________________________________
> > Rcpp-devel mailing list
> > Rcpp-devel at lists.r-forge.r-project.org
> > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20180117/205d5328/attachment-0001.html>