[Rd] A question about multiple(?) out of order ReleaseObject

Simon Urbanek simon.urbanek at r-project.org
Fri Mar 7 04:05:35 CET 2014

On Mar 6, 2014, at 5:32 PM, Saptarshi Guha <saptarshi.guha at gmail.com> wrote:

> Hello,
> This  is a question that probably reveals my lack of understanding.
> In a C function (call it cfunc), i created a SEXP, called S, and then
> called R_PreserveObject on S.
> I returned the SEXP to the calling R function (call it rfunc). Note, I
> didn't call
> R_ReleaseObject on S.
> v <- .Call("cfunc")
> So, are the following  statements correct
> 1.  S is 'doubly' protected from the GC by  being associated both with 'v'
> and because it has been added to the precious list (via a call to
> R_PreserveObject without ReleaseObject being called)


> 2. I have another C function called cfunc2. In cfunc2, I call
> R_ReleaseObject on S.  S , however, is still protected from the GC, because
> it is associated with 'v'

yes (assuming the binding to v still exists at that point). Note, however, that is such a case you R_PreserveObject() is pointless since you don't need to protect it on exit (that's in fact the convention - return results are never protected).

> Is (1) and (2) correct?
> I have not used R_protect/unprotect, because if I return from cfunc without the equivalent number of unprotects, i get 'unbalanced stack' warnings. I'd rather not have to worry about that because i intend to balance it later.

Normally, you should not keep the result of a function protected since it means you *have* to guarantee the unprotect at a later point. That is in general impossible to guarantee unless you have another object that is holding a reference that will be cleared by an explicitly registered finalizer. So unless that is the case, you are creating an explicit leak = bad. If you don't have as stack-like design, you can always use explicitly managed object for the lifetime (personally, I prefer that) since all chained objects are protected by design, or use REPROTECT.


> Regards
> Saptarshi
> 	[[alternative HTML version deleted]]
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

More information about the R-devel mailing list