search for: r_registercfin

...n++; SET_SLOT(vntObj, HandleSlotSymbol, vntHandle); PROTECT(vntData = R_ExternalPtrProtected(vntHandle)); n++; PROTECT(vntAttr = NEW_INTEGER(1)); n++; INTEGER(vntAttr)[0] = count; SET_COUNT(vntData, vntAttr); >>>>> Problem comes here <<<<<< R_RegisterCFinalizer(vntData, (R_CFinalizer_t)ProbesetGE_finalizer); UNPROTECT(n); return vntObj; } Thanks for any pointers... ---------------------------------------------------------- SIGSIG -- signature too long (core dumped)

Dear R .Call() insiders, Can someone enlighten me how to properly finalize external pointers in C code (R-2.5.1 win)? What is the relation between R_ClearExternalPtr and the finalizer set in R_RegisterCFinalizer? I succeeded registering a finalizer that works when an R object containing an external pointer is garbage collected. However, I have some difficulties figuring out how to do that in an explicit closing function. I observed that - calling R_ClearExternalPtr does not trigger the finalizer...

I see some code in R to attach finalizers to external pointer references (Register[C]Finalizer). Anyone have an example of how to code the finalizer? R_RegisterCFinalizer accepts a C function, but I can't see how to get it to operate on the pointer, since the pointer is not passed to the function when its called. RegisterFinalizer takes an R closure, but how is it called from R (tried .Internal)? Tim -- Timothy H. Keitt Department of Ecology and Evo...

On Tue, Dec 20, 2016 at 7:04 AM, Henrik Bengtsson <henrik.bengtsson at gmail.com> wrote: > On reason for hitting the MAX_NUM_DLLS (= 100) limit is because some > packages don't unload their DLLs when they being unloaded themselves. I am surprised by this. Why does R not do this automatically? What is the case for keeping the DLL loaded after the package has been unloaded? What

On Tue, Dec 20, 2016 at 7:39 AM, Karl Millar <kmillar at google.com> wrote: > It's not always clear when it's safe to remove the DLL. > > The main problem that I'm aware of is that native objects with > finalizers might still exist (created by R_RegisterCFinalizer etc). > Even if there are no live references to such objects (which would be > hard to verify), it still wouldn't be safe to unload the DLL until a > full garbage collection has been done. > > If the DLL is unloaded, then the function pointer that was registered > now be...

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 anyone give me some pointers? I haven't found much documentation. An earlier message

It's not always clear when it's safe to remove the DLL. The main problem that I'm aware of is that native objects with finalizers might still exist (created by R_RegisterCFinalizer etc). Even if there are no live references to such objects (which would be hard to verify), it still wouldn't be safe to unload the DLL until a full garbage collection has been done. If the DLL is unloaded, then the function pointer that was registered now becomes a pointer into the memo...

...ote: > On Tue, Dec 20, 2016 at 7:39 AM, Karl Millar <kmillar at google.com> wrote: >> It's not always clear when it's safe to remove the DLL. >> >> The main problem that I'm aware of is that native objects with >> finalizers might still exist (created by R_RegisterCFinalizer etc). >> Even if there are no live references to such objects (which would be >> hard to verify), it still wouldn't be safe to unload the DLL until a >> full garbage collection has been done. >> >> If the DLL is unloaded, then the function pointer that was re...

...>node) xmlFreeNode(c->node); } [...] // allocate the context and tell R to manage its protection and finalization // (you could write a macro to make this one-liner) my_context_t* c = (my_context_t*) R_Calloc(1, my_context_t); SEXP res = PROTECT(R_MakeExternalPtr(c, R_NilValue, R_NilValue)); R_RegisterCFinalizer(res, context_fin); // do all work here ... you safely abort at any point without memory leaks c->node = xmlNewNode(...); c->ctx = EVP_PKEY_CTX_new(...); [...] The point of using a finalizer is that no matter what happens the memory is always released. The structure with all allocatio...

Dear All, I would like to have an advice for designing an R library, and thought that R-devel may be the best place to ask given so many people who are highly expert in R are around. We are at an early stage of designing an R library, which is effectively an interface to a C++ library providing fast access to large matrices stored on HDD as binary files. The core of the C++ library is

WRE explains that R_alloc() can be used to allocate memory which automatically gets released by R at the end of a .C, .Call or .External, even in the case of an error or interruption. This is a really great feature to prevent memory leaks. I was wondering if there is a way to extend this mechanism to allow for automatically running UNPROTECT and custom finalizers at the end of a .Call as well.

Dear all, I have wrapped a C++ function in an R package. I allocate/deallocate memory using C++ 'new' and 'delete'. In order to allow user interrupts without memory leaks I've moved all the delete statements required after an interrupt to a separate C++ function freeMemory(), which is called using on.exit() just before the .C() call. I am concerned about the

Hi, I have followed the recommended steps for creating a package (rctest). As of now, my goal is simply to understand how various pieces fit together. The package includes: (1) C code with source in sub-directories, compiled to create a static library. (a) There is a single C-struct (dns) a simple 'matrix': {int m; int n; double *d;} (b) C code to create random matrix of a certain size.

...R_ClassSymbol U R_ExternalPtrAddr U R_ExternalPtrTag U R_GlobalEnv U R_MakeExternalPtr U R_NaInt U R_NamesSymbol U R_NilValue U R_PreserveObject U R_RegisterCFinalizer U R_ReleaseObject U R_alloc 0000000000003a90 T R_base64_decode 0000000000003910 T R_base64_encode 0000000000005060 T R_call_R_write_function 0000000000003bc0 T R_check_bits 00000000000047f0 T R_curlMultiPerform 0000000000004db0 T R_curl_BinaryData_free 000000...

...R_ClassSymbol U R_ExternalPtrAddr U R_ExternalPtrTag U R_GlobalEnv U R_MakeExternalPtr U R_NaInt U R_NamesSymbol U R_NilValue U R_PreserveObject U R_RegisterCFinalizer U R_ReleaseObject U R_alloc 0000000000003a90 T R_base64_decode 0000000000003910 T R_base64_encode 0000000000005060 T R_call_R_write_function 0000000000003bc0 T R_check_bits 00000000000047f0 T R_curlMultiPerform 0000000000004db0 T R_curl_BinaryData_free 000000...

...v R_NilValue R_DotsSymbol Rf_allocVector Rf_eval Rf_install Rf_isFunction Rf_isLanguage Rf_isValidString Rf_lcons Rf_length Rf_mkChar Rf_mkString Rf_protect Rf_unprotect R_CHAR STRING_ELT SET_STRING_ELT VECTOR_ELT INTEGER REAL TAG CDR CADR CADDR FORMALS PRINTNAME R_MakeExternalPtr R_ExternalPtrAddr R_RegisterCFinalizer R_PolledEvents R_wait_usec R_ParseVector R_timeout_handler R_timeout_val ptr_gnome_start mkdir -p -- ../../../../library/tcltk/libs gmake[5]: Leaving directory `/soft/R/R-1.5.1/src/library/tcltk/src' gmake[4]: Leaving directory `/soft/R/R-1.5.1/src/library/tcltk/src' gmake[3]: Leaving...