[Rcpp-devel] Rcpp Lists and memory corruption (resend)

Ilya Esteban bbc5019 at live.com
Wed Jul 4 00:47:52 CEST 2012


Just wanted to confirm that my code returning a list containing wrapped primitives appears to work correctly now. Sorry for the delayed reply -- I am not a SVN user, so I had to wait for the official release before validating. Thanks!
Ilya

> Date: Sat, 7 Apr 2012 15:19:27 +0200
> From: romain at r-enthusiasts.com
> To: rcpp-devel at lists.r-forge.r-project.org
> CC: bbc5019 at live.com
> Subject: Re: [Rcpp-devel] Rcpp Lists and memory corruption (resend)
> 
> Hello,
> 
> rev 3565 should address this issue. Thanks again for the bug report.
> 
> This was indeed due to SEXP not being protected sufficiently. 
> List::create allocates a new object, which might cause the GC to collect 
> one of the unprotected SEXP passed in.
> 
> Let me know if this works for you.
> 
> Romain
> 
> Le 31/03/12 11:35, Romain Francois a écrit :
> > Some head scratching this morning.
> >
> > If I have this:
> > return Rcpp::List::create(Rcpp::Named( "testVar" ) = 10 ) ;
> >
> > instead of:
> > return Rcpp::List::create(Rcpp::Named( "testVar" ) = wrap(10) ) ;
> >
> > everything runs smoothly.
> >
> >
> >
> > So my guess is that the SEXP that is made in the wrap call does not get
> > sufficient protection.
> >
> > Not sure this is an Rcpp bug or a user bug, but there might be somethign
> > I can do to prevent it.
> >
> > Romain
> >
> >
> > Le 31/03/12 09:20, Ilya E a écrit :
> >> (Apologies for sending this twice -- the formatting on the first email
> >> got completely mangled)
> >>
> >>
> >> Are there any known issues regarding memory corruption caused by lists
> >> created inside of Rcpp? I started noticing some inconsistencies in the
> >> data returned by my app, and was able to reduce the issue to the
> >> following reproducible example. It seems to suggest that lists created
> >> in Rcpp and returned to R can cause sporadic memory corruption. See
> >> code below for a demonstration:
> >>
> >> require(inline)
> >> require(Rcpp)
> >>
> >> testFun <- local( {
> >> fun <- cxxfunction(
> >> signature(), '
> >> return Rcpp::List::create(Rcpp::Named( "testVar" ) = wrap(10));
> >> ', plugin = "Rcpp" )
> >>
> >> function(){
> >> fun()
> >> }
> >> } )
> >>
> >> # generate the result set -- you would expect a numeric vector that
> >> consists of repetition of the value 10
> >> testOutcome = mapply(
> >> function(i) {
> >> fTouch = testFun()
> >> return(fTouch$testVar)
> >> },
> >> 1:5612062)
> >>
> >> # The result ensd up being something other than what you'd expect
> >> typeof(testOutcome)
> >> for (i in 1:length(testOutcome)) {
> >> if (testOutcome[[i]] != 10) {
> >> cat(i, "\n")
> >> }
> >> }
> >>
> >> You'll notice two things here. First, mapply fails to coerce the
> >> returned results to a vector (since in some cases the return from
> >> testFun seems to have more than 1 element) and second, not all return
> >> values are equal to 10, as you would expect. The actual position in
> >> the vector of the corrupted data is sporadic. If you keep running this
> >> over and over again, you'll see the wrong value in different places.
> >> Sometimes you can even get R to crash after multiple runs. On rare
> >> occasions there will be no errors at all. For some reason you tend to
> >> see the most errors on the first run, especially if you open a new
> >> instance of R.
> >>
> >> If you replace the line "fTouch = testFun()" with a native call to R
> >> "fTouch = list(testVar = 10)" then everything works fine. Also
> >> returning a NumericVector instead of a list also works fine -- the
> >> issue seems to appear after encapsulating the return value in a list
> >> inside of Rcpp.
> >>
> >> I am using R 2.14.2 on Win32& Win64. Rcpp version 0.9.10.
> >>
> >> Thanks,
> >> Ilya
> >
> 
> 
> -- 
> Romain Francois
> Professional R Enthusiast
> +33(0) 6 28 91 30 30
> R Graph Gallery: http://addictedtor.free.fr/graphiques
> blog:            http://romainfrancois.blog.free.fr
> |- http://bit.ly/xbKv0R : Crawling facebook with R
> |- http://bit.ly/v3WB8S : ... And now for solution 17, still using Rcpp
> `- http://bit.ly/uaQDGr : int64: 64 bit integer vectors for R
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20120703/620a90f4/attachment.html>


More information about the Rcpp-devel mailing list