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
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 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
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
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
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
Dear Developers,
I've been struggling through writing R extension in C. I've been using
an external pointer to store my data (please see sample below). I
encountered a very weird erroneous behaviour: when I tried to use my
external pointer to a structure holding several types of data,
including S
Patrick,
On Dec 28, 2011, at 12:07 AM, Patrick Leyshock wrote:
> I have an external pointer object that I'd like to pass from my R code to
> some C code. Per Section 5.13 of "Writing R Extensions", I've noted that
> "external pointers should only be used as part of an object with normal
> semant
I have an external pointer object that I'd like to pass from my R code to
some C code. Per Section 5.13 of "Writing R Extensions", I've noted that
"external pointers should only be used as part of an object with normal
semantics, for example an attribute or an element of a list." So I've
written
98== 135,792 bytes in 69 blocks are possibly lost in loss record 1,832
> of 1,858
> ==22098==at 0x4C274A8: malloc (vg_replace_malloc.c:236)
> ==22098==by 0x4F5D799: GetNewPage (memory.c:786)
> ==22098==by 0x4F5EE6F: Rf_allocVector (memory.c:2330)
> ==22098==by 0x4F6007F:
=by 0x4E6F3D8: do_lapply (apply.c:72)
Thanks for any help!
jim
____
From: Simon Urbanek [simon.urba...@r-project.org]
Sent: Thursday, September 15, 2011 8:35 AM
To: James Bullard
Cc: r-devel@r-project.org
Subject: Re: [Rd] External pointers and an apparent m
Jim,
On Sep 14, 2011, at 5:21 PM, James Bullard wrote:
> I'm using external pointers and seemingly leaking memory. My determination of
> a memory leak is that the R process continually creeps up in memory as seen
> by top while the usage as reported by gc() stays flat. I have isolated the C
>
James,
Works for me!
In a file, 'test.c', I have:
void h5R_allocate_finalizer(SEXP eptr) {
char* vector = (char*) R_ExternalPtrAddr(eptr);
free(vector);
printf("memory freed at address %lu\n", (long unsigned) vector);
R_ClearExternalPtr(eptr);
}
SEXP h5R_allocate(SEXP size) {
I'm using external pointers and seemingly leaking memory. My determination of a
memory leak is that the R process continually creeps up in memory as seen by
top while the usage as reported by gc() stays flat. I have isolated the C code:
void h5R_allocate_finalizer(SEXP eptr) {
Rprintf("Calli
On Mon, 12 Dec 2005, Byron Ellis wrote:
> There's also Luke's own site, in particular http://www.stat.uiowa.edu/
> ~luke/R/weakfinex.html
Hmm, that _is_ a link on the page I pointed you to, under its actual
subject, weak references.
> On Dec 12, 2005, at 12:16 AM, Prof Brian Ripley wrote:
>
>>
There's also Luke's own site, in particular http://www.stat.uiowa.edu/
~luke/R/weakfinex.html
On Dec 12, 2005, at 12:16 AM, Prof Brian Ripley wrote:
> On Mon, 12 Dec 2005, Roger Bivand wrote:
>
>>> Where would be best to read about externalptr? I'm having trouble
>>> finding material in the manu
On Mon, 12 Dec 2005, Roger Bivand wrote:
>> Where would be best to read about externalptr? I'm having trouble
>> finding material in the manuals or the site-search.
>>
>> And would I need to use all the .Call machinery and C headers and SEXP
>> etc in order to handle externalptr objects?
>
> One p
On Mon, 12 Dec 2005 [EMAIL PROTECTED] wrote:
> Hi Simon
>
> Thanks for that... see below for my feeble counterblasts! (And two
> questions.)
>
> > Mark,
> >
> > On Dec 12, 2005, at 7:48 AM, <[EMAIL PROTECTED]> wrote:
> >
> > > (i)The first '.C' call uses Delphi code to allocate (using Delphi's
Hi Simon
Thanks for that... see below for my feeble counterblasts! (And two
questions.)
> Mark,
>
> On Dec 12, 2005, at 7:48 AM, <[EMAIL PROTECTED]> wrote:
>
> > (i)The first '.C' call uses Delphi code to allocate (using Delphi's
> > own memory manager) and set up a persistent object that R
>
Mark,
On Dec 12, 2005, at 7:48 AM, <[EMAIL PROTECTED]> wrote:
> (i)The first '.C' call uses Delphi code to allocate (using Delphi's
> own memory manager) and set up a persistent object that R doesn't
> know about. The Delphi code then returns an "opaque" integer-valued
> handle to R, which
clear.
HTH
Mark
Mark Bravington
CSIRO Mathematical & Information Sciences
Marine Laboratory
Castray Esplanade
Hobart 7001
TAS
ph (+61) 3 6232 5118
fax (+61) 3 6232 5012
mob (+61) 438 315 623
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On B
use a C finalizer...
void MyObject_finalize(SEXP opaque) {
MyObject *obj = (MyObject*)R_ExternalPtrAddr(opaque);
if(NULL != obj) delete obj;
}
and in your setup code...
PROTECT(p = R_MakeExternalPtr(...));
R_RegisterCFinalizer(p,MyObject_finalize);
On Dec 9, 2005, at 3:04 P
I have some C data I want to pass back to R opaquely, and then back to
C. I understand external pointers are the way to do so.
I'm trying to find how they interact with garbage collection and object
lifetime, and what I need to do so that the memory lives until the
calling R process ends.
Could
23 matches
Mail list logo
