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

[Alexis Sarda]

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 <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20180120/9a1be6af/attachment.html>