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

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