Passing SEXP objects between C functions using PROTECT and UNPROTECT correctly - r

Question

I have an issue with the Valgrind check on CRAN for a package. While I cannot reproduce the issue, I suspect I know what the issue is. A simplified example is this C++ file:
#include <Rcpp.h>
using namespace Rcpp;
// what I currently do
// call a R function with 1 argument
SEXP do_work1(SEXP x, SEXP fn, SEXP env){
SEXP R_fcall, out;
PROTECT(R_fcall = Rf_lang2(fn, x));
PROTECT(out = Rf_eval(R_fcall, env));
UNPROTECT(2);
return out;
}
bool not_ok(SEXP x, R_len_t const ex_len){
return !Rf_isReal(x) or !Rf_isVector(x) or Rf_xlength(x) != ex_len or
Rf_isNull(x);
}
// [[Rcpp::export(rng = false)]]
double use_do_worka(SEXP x, SEXP fn, SEXP env){
SEXP res = do_work1(x, fn, env);
CharacterVector what("y");
SEXP y = Rf_getAttrib(res, what);
if(not_ok(res, 2) or not_ok(y, 1))
throw std::invalid_argument("not ok");
double out = *REAL(res) + REAL(res)[1] + *REAL(y);
return out;
}
// what I could do instead?
// [[Rcpp::export(rng = false)]]
double use_do_workb(SEXP x, SEXP fn, SEXP env){
SEXP res = PROTECT(do_work1(x, fn, env)); // added PROTECT
CharacterVector what("y");
SEXP y = PROTECT(Rf_getAttrib(res, what)); // added PROTECT
if(not_ok(res, 2) or not_ok(y, 1)){
UNPROTECT(2); // added UNPROTECT
throw std::invalid_argument("not ok");
}
double out = *REAL(res) + REAL(res)[1] + *REAL(y);
UNPROTECT(2); // added UNPROTECT
return out;
}
// or maybe?
SEXP do_work2(SEXP x, SEXP fn, SEXP env){
SEXP R_fcall, out;
PROTECT(R_fcall = Rf_lang2(fn, x));
PROTECT(out = Rf_eval(R_fcall, env));
// removed UNPROTECT
return out;
}
// [[Rcpp::export(rng = false)]]
double use_do_workc(SEXP x, SEXP fn, SEXP env){
SEXP res = do_work2(x, fn, env);
CharacterVector what("y");
SEXP y = PROTECT(Rf_getAttrib(res, what)); // added PROTECT
if(not_ok(res, 2) or not_ok(y, 1)){
UNPROTECT(3); // added UNPROTECT
throw std::invalid_argument("not ok");
}
double out = *REAL(res) + REAL(res)[1] + *REAL(y);
UNPROTECT(3); // added UNPROTECT
return out;
}
/*** R
f <- function(x) {
x1 <- x[1]
x2 <- x[2]
out <- c(-400 * x1 * (x2 - x1 * x1) - 2 * (1 - x1),
200 * (x2 - x1 * x1))
attr(out, "y") <- 100 * (x2 - x1 * x1)^2 + (1 - x1)^2
out
}
for(i in 1:1000000){
use_do_worka(1, f, .GlobalEnv)
use_do_workb(1, f, .GlobalEnv)
use_do_workc(1, f, .GlobalEnv)
}
*/
which one can compile and run the examples using Rcpp::sourceCpp. do_work1 and use_do_worka is very similar to what I currently do. However, I suspect that res and y may be garbage collected in use_do_worka. Is this true?
If so then use_do_workb PROTECT both of them again. Is this a good and correct way to pass SEXP objects between C functions? That is, re-protect the returned object from another C function?
Lastly, do_work2 and use_do_workc is very similar use_do_workb but save one PROTECT call. However, it adds the burden that one has to remember to UNPROTECT which I gather can easily lead to a bug. Is this version still valid?
Remarks
I have tried to run
R -d valgrind -e "Rcpp::sourceCpp('[name-of-file-w-above-code].cpp')"
but this does not cause any issues. I have also tried to R CMD check --use-valgrind the package but I cannot reproduce the issue on CRAN.
The actually error I get from CRAN is:
==4144090== Invalid read of size 8
==4144090== at 0x483EDED: memcpy#GLIBC_2.2.5 (/builddir/build/BUILD/valgrind-3.16.1/memcheck/../shared/vg_replace_strmem.c:1032)
==4144090== by 0x1736C2AC: copy (packages/tests-vg/psqn/src/../inst/include/lp.h:12)
==4144090== by 0x1736C2AC: r_worker_bfgs::grad(double const*, double*) (packages/tests-vg/psqn/src/r-api.cpp:353)
==4144090== by 0x17367754: PSQN::optim_info PSQN::bfgs<PSQN::R_reporter, PSQN::R_interrupter>(PSQN::problem&, double*, double, unsigned long, double, double, int)::{lambda(double, double*, double*, double*, double&)#4}::operator()(double, double*, double*, double*, double&) const (packages/tests-vg/psqn/src/../inst/include/psqn-bfgs.h:148)
with
packages/tests-vg/psqn/src/../inst/include/lp.h:12.
packages/tests-vg/psqn/src/r-api.cpp:353.
where I know that the vector has the right length which makes me suspect that it has been garbage collected because of the invalid read of size 8 error. The vector is created with very similar code as in my example above.