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

Romain Francois romain at r-enthusiasts.com
Sat Apr 7 15:19:27 CEST 2012


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


More information about the Rcpp-devel mailing list