Offhand, I'd say that if "all protects get unprotected before return"
mydata->ans is not protected against garbage collection, and thus very likely
collected and reused. If mydata is created by Calloc, the GC has no way of
knowing that it might have pointers to things that are intended to persist
As far as I understood the documentation, external pointer should be
automatically protected from gc when returned to environment. The
solution you've just suggested would cause stack imbalance.
Recently I've been thinking of encapsulating the pointer into a nice
object using Rcpp. This sounds bett
Hi,
One solution to protect an object from the GC is to use the R_PreserveObject
and R_ReleaseObject functions.
This way, you are not subject to the stack that PROTECT, UNPROTECT,
UNPROTECT_PTR uses.
Using R_PreserveObject and R_ReleaseObject is one of the best things that has
ever happene
On 16/12/2013 11:07, Krzysztof Mlynarczyk wrote:
As far as I understood the documentation, external pointer should be
automatically protected from gc when returned to environment. The
Yes, but you didn't give us the complete reproducible example the
posting guide asks for. Peter's diagnosis i
Yes, it turned out that using R_PreserveObject and R_ReleaseObject
solved that problem.
I sincerely apologize for posting only several chunks of code.
Fortunately for me, the descritpion I gave was sufficient to track
down what was missing.
Thank you very much!
Chris
2013/12/16 Prof Brian Ripley
On 12/16/2013 09:18 AM, Krzysztof Mlynarczyk wrote:
Yes, it turned out that using R_PreserveObject and R_ReleaseObject
solved that problem.
Instead I think you want to use the third argument to R_MakeExternalPtr to
protect the SEXP's you'd like to persist for the duration of the object, maybe
