<div dir="ltr">(I think I forgot to reply to all)<div><br></div><div><span style="font-size:12.8px">I failed to mention that I am also using RcppArmadillo elsewhere,</span><div style="font-size:12.8px">and I found the following post by the Coatless Professor saying that Armadillo requires at least gcc 4.7.2:<br><br><a href="http://thecoatlessprofessor.com/programming/r/selecting-an-alternative-compiler-for-r-package-testing-on-travis-ci/" target="_blank">http://thecoatlessprofessor.co<wbr>m/programming/r/selecting-an-a<wbr>lternative-compiler-for-r-pack<wbr>age-testing-on-travis-ci/</a><br><br>However, my Travis builds were already using Trusty (gcc 4.8.4).</div><div style="font-size:12.8px">I think WinBuilder uses gcc 4.9.3, and that one didn't fail.</div><div style="font-size:12.8px">In case it is of interest, I am using Armadillo for exactly one thing:<div><br></div><div>arma::vec cc_seq = arma::real(arma::ifft(fftx % ffty));</div><div><br></div><div>and that was also being problematic in Travis</div><div>(element-wise multiplication due to incompatible dimensions, showing vectors with unreasonably large dimensions).</div><div>Using version 5 of the compilers as explained in the post above seems to have solved the problems.</div><div><div><br>Thanks,<br>Alexis. </div></div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 17, 2018 at 5:41 PM, Kevin Ushey <span dir="ltr"><<a href="mailto:kevinushey@gmail.com" target="_blank">kevinushey@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In your RcppParallel worker, it looks like you're trying to write to<br>
an Rcpp matrix; e.g. you have:<br>
<br>
    distmat_(i,j) = local_calculator->calculate(i,<wbr>j);<br>
<br>
where distmat_ is a matrix. You should avoid using Rcpp classes within<br>
RcppParallel workers, as there's no guarantee that the methods<br>
available on Rcpp classes are thread-safe (and this could lead to<br>
these kinds of segfaults).<br>
<br>
I'll echo Dirk and say that without a minimally reproducible example<br>
(or access to the package source code) there's not much else we can<br>
say.<br>
<br>
You could try running your code with `gctorture(TRUE)` to see if that<br>
triggers your segfault more reliably -- if that's the case, then you<br>
almost surely have an protection issue somewhere (most likely the<br>
result of using non-threadsafe APIs within an RcppParallel worker, but<br>
without full context it's impossible to be sure)<br>
<div><div class="h5"><br>
On Wed, Jan 17, 2018 at 4:32 AM, Dirk Eddelbuettel <<a href="mailto:edd@debian.org">edd@debian.org</a>> wrote:<br>
><br>
> On 16 January 2018 at 21:02, Alexis Sarda wrote:<br>
> | Hello,<br>
> |<br>
> | I am integrating RcppParallel into my R package and I'm running into<br>
> | strange problems with segmentation faults, but only during the continuous<br>
> | integration checks. I have essentially variations of the following (I hope<br>
> | GitHub gist links are ok):<br>
> |<br>
> | <a href="https://gist.github.com/asardaes/7d78af394f848a967997ff23e433c9cf" rel="noreferrer" target="_blank">https://gist.github.com/<wbr>asardaes/<wbr>7d78af394f848a967997ff23e433c9<wbr>cf</a><br>
> |<br>
> | On TravisCI, my Linux builds simply freeze, and the OSX builds show<br>
> | messages like:<br>
> |<br>
> | *** caught segfault ***<br>
> | address 0x100000001, cause 'memory not mapped'<br>
> |<br>
> | I would assume that my distance functions are trying to access memory they<br>
> | shouldn't, but during interactive use everything works flawlessly, and I've<br>
> | tested all of the following with no problems (which also test correctness,<br>
> | i.e. numeric consistency with respect to past results):<br>
> |<br>
> | - Local Linux R CMD check<br>
> | - Local Windows R CMD check<br>
> | - CRAN's WinBuilder check<br>
> | - AppVeyor (x32 and x64 Windows)<br>
> | - Docker R CMD check using rocker's r-devel-san<br>
> | - Local Linux R CMD check with valgrind (no leaks)<br>
> |<br>
> | It is worth mentioning that some of the examples ran during the OSX build<br>
> | show incorrect results long before the segfault occurs: some results are<br>
> | zero when they shouldn't be. I don't have access to a machine with OSX, but<br>
> | the Linux builds in TravisCI also show problems (no segfaults explicitly,<br>
> | just hangs).<br>
> |<br>
> | I am at my wit's end. Any input would be appreciated.<br>
><br>
> Hard to tell for us, but maybe try the old and trusted route of smaller and<br>
> smaller reproducible examples til you reproduce it?<br>
><br>
> Or else if it _just_ Travis CI maybe it is a compiler version issue?  Travis<br>
> is very conservative in its default setup but there are .travis.yaml scripts<br>
> out there that turn on the PPA for compiler builds giving you gcc-5, gcc-6,<br>
> ... amd different clang versions.<br>
><br>
> Dirk<br>
><br>
> --<br>
> <a href="http://dirk.eddelbuettel.com" rel="noreferrer" target="_blank">http://dirk.eddelbuettel.com</a> | @eddelbuettel | <a href="mailto:edd@debian.org">edd@debian.org</a><br>
</div></div>> ______________________________<wbr>_________________<br>
> Rcpp-devel mailing list<br>
> <a href="mailto:Rcpp-devel@lists.r-forge.r-project.org">Rcpp-devel@lists.r-forge.r-<wbr>project.org</a><br>
> <a href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel" rel="noreferrer" target="_blank">https://lists.r-forge.r-<wbr>project.org/cgi-bin/mailman/<wbr>listinfo/rcpp-devel</a><br>
</blockquote></div><br></div>