[Rcpp-devel] Segfault error during simulation in Rcpp

Matteo Fasiolo matteo.fasiolo at gmail.com
Thu May 16 15:23:34 CEST 2013


Hi all,

 I'm writing again about the segfault problem during simulation.
I have added the missing line:

RNGScope scope;

and I have got rid of all temporary expressions.
After that everything seemed to go well, actually to make sure it
was working I run 10^8 iterations in 4 R session without getting any
segfault.
It must be noted that if I run the program in valgrind I am still
(occasionally) getting
output like:

==9697==  Address 0xb214b10 is 0 bytes inside a block of size 440 free'd
==9697==    at 0x4C2A82E: free (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==9697==    by 0x4F43B8F: ??? (in /usr/lib/R/lib/libR.so)
==9697==    by 0x4F4661F: Rf_allocVector (in /usr/lib/R/lib/libR.so)
==9697==    by 0x4E65E1F: PutRNGstate (in /usr/lib/R/lib/libR.so)
==9697==    by 0xDF4CC8D: sourceCpp_94930_rickerCpp (random.h:71)
==9697==    by 0x4ED4F12: ??? (in /usr/lib/R/lib/libR.so)
==9697==    by 0x4F1368B: Rf_eval (in /usr/lib/R/lib/libR.so)
==9697==    by 0x4F16ABC: Rf_applyClosure (in /usr/lib/R/lib/libR.so)
==9697==    by 0x4F1333F: Rf_eval (in /usr/lib/R/lib/libR.so)
==9697==    by 0x4F152EF: ??? (in /usr/lib/R/lib/libR.so)
==9697==    by 0x4F1345E: Rf_eval (in /usr/lib/R/lib/libR.so)
==9697==    by 0x4F1546F: ??? (in /usr/lib/R/lib/libR.so)

The problem is that the segfaults are back, so I tried to simplify my code
to see what is going on.
I have arrived to the following version:

// [[Rcpp::export]]
NumericMatrix rickerCpp(int days, int nSimul, int nBurn, NumericVector
params)
{
  RNGScope scope;

  int nParams = params.size();
  int totDays = nBurn + days;

  double r = exp(params(0));
  double sigma = exp(params(1));
  double phi = exp(params(2));

  double initState = 1.0;
  double currState;

  NumericMatrix output( nSimul, days );

  for(int iRow = 0; iRow < nSimul; iRow++)
  {

   currState = initState;

   for(int iCol = 1; iCol <= nBurn; iCol++){
     currState = r * currState * exp( - currState );
   }

   output(iRow, 0) = phi * currState;

   for(int iCol = 1; iCol < days; iCol++){
     currState = r * currState * exp( - currState );
     output(iRow, iCol) = phi * currState;
   }

  }

  return output;

}

actually here I'm not calling any rnorm() or rpois() anymore. If I run it
in R:

library(Rcpp)
sourceCpp("~/Desktop/a.cpp")

days <- 50
nBurn <- 50
nSimul <- 1

set.seed(545784365)
for(ii in 1:10^6)
{
  params <- log(c(r = 44.7, sigma = 0.3, phi = 10))
  res <- rickerCpp(days, nSimul = nSimul, nBurn, params = params)
  res <- t(res)
}

I can do 10^7 iteration without problems or it might crash immediately with
message:

 *** caught segfault ***
address 0x6d6994, cause 'memory not mapped'

Traceback:
 1: t(res)

up to 6 time in a row (also pointing at the same address 0x6d6994)!
In addition valgrind still gives the same message about PutRNGstate etc...
Probably it's just my impression, but segfaults seem to correlate between R
sessions: few sessions run fine and then they just keep crashing.

Sorry for the long message but I'm really clueless (as I said 4 by 10^8
iterations
and it is fine, then it crashes several times then it is fine again?).
Thanks,

Matteo










On Thu, May 9, 2013 at 5:04 PM, Jared Murray <jmurray.1022 at gmail.com> wrote:

> I have had a similar experience; I wrote a small-moderate sized
> function to do some simulations and tested via sourceCpp() (and
> included an explicit instance of RNGScope() as well)  with no problems
> whatever. Then I wrote a wrapper to this function and tried running it
> in parallel with mclapply and got intermittent segfaults. When I
> backed off and tried just running the wrapper function itself the
> (intermittent) segfaults persisted. I tried several things, including
> moving the function into a package, but none of these helped.
>
> Refactoring the code to use fewer temporaries fixed the problem.  I
> got the hint by adding some debug messages and turning on gcinfo(),
> and watching it segfault every time gc happened while the function was
> executing.. I tried to reproduce the bug with something simple but had
> no luck, and since the fix ended up being writing code that wasn't
> stupid I let it pass :) But you might try the same Matteo, as you seem
> to be in a very similar boat.
>
> As an aside, you can replace code like this:
> rpois(1, phi * currState)[0];
>
> with a call to the original Rmath function using the R:: namespace
> R::rpois( phi * currState);
>
> since you don't need the (wonderful!) sugar vectorization.
>
> On Mon, May 6, 2013 at 2:47 PM, Matteo Fasiolo <matteo.fasiolo at gmail.com>
> wrote:
> > Ok, I'll do exactly this and I'll report if I still encounter this
> > problem in simpler programs. Thanks.
> >
> >
> > On Mon, May 6, 2013 at 7:39 PM, Dirk Eddelbuettel <edd at debian.org>
> wrote:
> >>
> >>
> >> On 6 May 2013 at 19:03, Matteo Fasiolo wrote:
> >> | Sorry for the silly question, but since I'm using sourceCpp() too I
> >> should't
> >> | call
> >> | getRNGstate/putRNGstate, right?
> >>
> >> If you use any of the random number generators provided by R via Rcpp,
> >> then
> >> you __MUST__ also instantiate an RNGScope() object (which does this for
> >> you).
> >>
> >> We documented this *very* clearly in a number of places in the
> >> documentation.
> >>
> >> (And yes, sourceCpp() adds one as a courtesy but you should still add
> >> one. The extra few nanoseconds in execution speed won't matter.)
> >>
> >> You report is otherwise still unreproducible at my end.
> >>
> >> Your program is also complex in that it does a few things.  Try writing
> >> smaller and smaller programs still exhibiting the error at your end.
>  And
> >> do
> >> report back if you find something, or have questions.
> >>
> >> Dirk
> >>
> >> --
> >> Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com
> >
> >
> >
> > _______________________________________________
> > 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/20130516/7e910397/attachment.html>


More information about the Rcpp-devel mailing list