[Rcpp-devel] why is memory freed in assignment to RObject

[Antonio Piccolboni]

Hi,
I develop a package called rmr2 and we've run into some hard-to-track
instability of late. R CMD check fails on an assertion, but if we execute
the same test any other way (interactive, batch, vanilla, anything) it
passes. If we comment out that test, R CMD check fails somewhere else. I
suspect some dynamic memory problems so I executed the test in valgrind. I
don't normally do that but I should. I figured I have no clue what the
problem is, but if I get a clean valgrind output that can only improve my
condition. Needless to say I get a lengthy valgrind report and I am
focusing on the first entry



Invalid read of size 1
    at 0x4ECDAA1: ??? (in /usr/lib64/R/lib/libR.so)
    by 0x4E7CD6E: ??? (in /usr/lib64/R/lib/libR.so)
    by 0x4E82C52: ??? (in /usr/lib64/R/lib/libR.so)
    by 0x4E83042: ??? (in /usr/lib64/R/lib/libR.so)
    by 0x4EF7EE5: Rf_eval (in /usr/lib64/R/lib/libR.so)
    by 0x4EFB027: ??? (in /usr/lib64/R/lib/libR.so)
    by 0x4EF7D9B: Rf_eval (in /usr/lib64/R/lib/libR.so)
    by 0x4EFB1BF: ??? (in /usr/lib64/R/lib/libR.so)
    by 0x4EF7D9B: Rf_eval (in /usr/lib64/R/lib/libR.so)
    by 0x4EFCA94: ??? (in /usr/lib64/R/lib/libR.so)
    by 0x4EF7D9B: Rf_eval (in /usr/lib64/R/lib/libR.so)
    by 0x4EFB1BF: ??? (in /usr/lib64/R/lib/libR.so)
  Address 0xfd49a60 is 0 bytes inside a block of size 176 free'd
    at 0x4C273F0: free (vg_replace_malloc.c:446)
    by 0x4F22270: ??? (in /usr/lib64/R/lib/libR.so)
    by 0x4F23DA9: Rf_cons (in /usr/lib64/R/lib/libR.so)
    by 0x4F23E0F: R_PreserveObject (in /usr/lib64/R/lib/libR.so)
    by 0x1418BFB4: Rcpp::Rcpp_PreserveObject(SEXPREC*) (api.cpp:66)
    by 0x1418C40C: Rcpp::Rcpp_ReplaceObject(SEXPREC*, SEXPREC*)
(api.cpp:146)
    by 0x1418C43C: Rcpp::RObject::setSEXP(SEXPREC*) (api.cpp:253)
    by 0x1418DB58: Rcpp::RObject::operator=(SEXPREC*) (api.cpp:269)
    by 0x13F46FBA: unserialize(std::deque<unsigned char,
std::allocator<unsigned char> > const&, int&, int) (typed-bytes.cpp:323)
    by 0x13F4880F: unserialize_list(std::deque<unsigned char,
std::allocator<unsigned char> > const&, int&) (typed-bytes.cpp:204)
    by 0x13F47233: unserialize(std::deque<unsigned char,
std::allocator<unsigned char> > const&, int&, int) (typed-bytes.cpp:277)
    by 0x13F47C59: typedbytes_reader (typed-bytes.cpp:352)

So there is a read access to freed memory. If one looks where it was freed
it's in an assignment  of a SEXP value to an RObject variable. The SEXP
value is returned by a function that calls  wrap called on an
std::vector<float>. To make my life simpler, or so I thought, I don't use
pointers anywhere in this program, so I don't do any memory management
explicitly myself. Not the most efficient, but for us the priority is to
safely move more functionality from R to C++, not to write optimized C++.
So my expectation was that wrap would create the appropriate SEXP from the
vector, a copy of that would be returned by wrap and then by the function I
wrote calling wrap and then a copy would be stored in an RObject variable.
So to sketch it out

SEXP unserialize (args ...) {
 std::vector<float> tmp;
 /// fill tmp with good stuff
return wrap(tmp);}

Robject var;

var = unserialize(args ...)
// free happens in here

That var gets wrapped and pushed_back onto a std::vector<SEXP>,  and after
many instances of the same process the vector gets wrapped and returned to
R.
I confess it's a little counterintuitive to me why R_PreserveObject would
be in charge of freeing any memory. I just assumed, maybe naively, that
 overloaded assignments would do the right thing. Any suggestions?

Environment:
R 3.0.2
Rcpp 10.0.6


Thanks

Antonio


PS: I know it's always best to provide a reproducible example, but believe
me it wasn't for lack of trying here! I tried to split the test into
smaller parts and already valgrind was not complaining anymore. I also
tried to create the same programming pattern in a standalone Rcpp snippet,
absolutely no errors.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20140125/b61bae2a/attachment.html>