Protect function argument to rcpp_set_stack_trace()

[krlmlr]

which may be gc-ed otherwise.

I was unable to create a reproducible example for this problem, but I have two stack traces from test runs for dplyr with valgrind and gctorture enabled that indicate that this may be the source of a problem. I'm not seeing these errors anymore after applying this fix.

[eddelbuettel]

There has never been an entry Bug fixes. Please place under Rcpp API.

[eddelbuettel]

Should this be Rcpp::Shield<> instead?

[eddelbuettel]

Also, remember that we (generally) prefer Issue tickets prior to PRs...

[krlmlr]

Next time I have a reprex I file an issue first. Promise ;-)

[codecov-io]

Codecov Report

Merging #706 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #706   +/-   ##
=======================================
  Coverage   89.57%   89.57%           
=======================================
  Files          66       66           
  Lines        3588     3588           
=======================================
  Hits         3214     3214           
  Misses        374      374

Impacted Files	Coverage Δ
inst/include/Rcpp/exceptions.h	50% <ø> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7687508...66cf2c6. Read the comment docs.

[eddelbuettel]

Thanks for quickly making the changes. Does it still pass your local test?

[kevinushey]

Thanks for catching this! I don't think this is quite the right change, though.

Normally, we should be able to operate under the assumption that SEXP arguments received by functions are already protected by someone in a parent scope; e.g. this is what is done for methods called from R through the .Call() interface and I think we should preserve these semantics in other C++-specific code as well.

It looks to me like the real issue here is that the SEXP returned by calls to stack_trace() is not protected, e.g. here:

Rcpp/inst/include/Rcpp/exceptions.h

Line 34 in 7687508

rcpp_set_stack_trace(stack_trace());

Rcpp/inst/include/Rcpp/exceptions.h

Line 39 in 7687508

rcpp_set_stack_trace(stack_trace(file,line));

And so the returned SEXP from stack_trace() should be protected before being sent to those function calls.

[eddelbuettel]

Next time I have a reprex I file an issue first. Promise ;-)

Well whether you want it or not we're having the review now :)

[krlmlr]

@kevinushey: Good point, thanks for chiming in.

@eddelbuettel: I'm fine with that.

[krlmlr]

Concerning the local test: I can no longer replicate the original heisenbug. I'll run a test on dplyr using this branch of Rcpp with valgrind and gctorture.

[krlmlr]

FWIW, Rf_ScalarString() does protect its argument.

[eddelbuettel]

FWIW, Rf_ScalarString() does protect its argument.

Meaning we'd no longer need this? Colour me confused.

In any event, this is unlikely to do harm, and as @kevinushey pointed out both a good catch anyway and now in a better spot so I'll merge.

[krlmlr]

I was pointing out that some functions seem to be caller-protected, others callee-protected. But then Rf_ScalarString() may just be the big exception of the rule, I don't know.

[lionel-]

The rule in the R source code is that the caller protects arguments and the callee can expect its arguments to be protected. There are documented exceptions, e.g. setAttrib().