<div dir="ltr">Hi,<br>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<br>
<br> <br><br>Invalid read of size 1<br> at 0x4ECDAA1: ??? (in /usr/lib64/R/lib/libR.so)<br> by 0x4E7CD6E: ??? (in /usr/lib64/R/lib/libR.so)<br> by 0x4E82C52: ??? (in /usr/lib64/R/lib/libR.so)<br> by 0x4E83042: ??? (in /usr/lib64/R/lib/libR.so)<br>
by 0x4EF7EE5: Rf_eval (in /usr/lib64/R/lib/libR.so)<br> by 0x4EFB027: ??? (in /usr/lib64/R/lib/libR.so)<br> by 0x4EF7D9B: Rf_eval (in /usr/lib64/R/lib/libR.so)<br> by 0x4EFB1BF: ??? (in /usr/lib64/R/lib/libR.so)<br>
by 0x4EF7D9B: Rf_eval (in /usr/lib64/R/lib/libR.so)<br> by 0x4EFCA94: ??? (in /usr/lib64/R/lib/libR.so)<br> by 0x4EF7D9B: Rf_eval (in /usr/lib64/R/lib/libR.so)<br> by 0x4EFB1BF: ??? (in /usr/lib64/R/lib/libR.so)<br>
Address 0xfd49a60 is 0 bytes inside a block of size 176 free'd<br> at 0x4C273F0: free (vg_replace_malloc.c:446)<br> by 0x4F22270: ??? (in /usr/lib64/R/lib/libR.so)<br> by 0x4F23DA9: Rf_cons (in /usr/lib64/R/lib/libR.so)<br>
by 0x4F23E0F: R_PreserveObject (in /usr/lib64/R/lib/libR.so)<br> by 0x1418BFB4: Rcpp::Rcpp_PreserveObject(SEXPREC*) (api.cpp:66)<br> by 0x1418C40C: Rcpp::Rcpp_ReplaceObject(SEXPREC*, SEXPREC*) (api.cpp:146)<br>
by 0x1418C43C: Rcpp::RObject::setSEXP(SEXPREC*) (api.cpp:253)<br>
by 0x1418DB58: Rcpp::RObject::operator=(SEXPREC*) (api.cpp:269)<br> by 0x13F46FBA: unserialize(std::deque<unsigned char, std::allocator<unsigned char> > const&, int&, int) (typed-bytes.cpp:323)<br>
by 0x13F4880F: unserialize_list(std::deque<unsigned char, std::allocator<unsigned char> > const&, int&) (typed-bytes.cpp:204)<br> by 0x13F47233: unserialize(std::deque<unsigned char, std::allocator<unsigned char> > const&, int&, int) (typed-bytes.cpp:277)<br>
by 0x13F47C59: typedbytes_reader (typed-bytes.cpp:352)<br><div><br></div><div>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</div>
<div><br></div><div>SEXP unserialize (args ...) {</div><div> std::vector<float> tmp;</div><div> /// fill tmp with good stuff</div><div>return wrap(tmp);}</div><div><br></div><div>Robject var;</div><div><br></div><div>
var = unserialize(args ...)</div><div>// free happens in here</div><div><br></div><div>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.</div>
<div>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? </div>
<div><br></div><div>Environment:</div><div>R 3.0.2<br></div><div>Rcpp 10.0.6</div><div><br></div><div><br></div><div>Thanks</div><div><br></div><div>Antonio</div><div><br></div><div><br></div><div>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.</div>
</div>