similar to: memory management in C code

Dear R-devel This one seems a bit arcane for R-help. I very often use R to call routines written in Delphi (son of Pascal), doing "persistent" memory allocation within Delphi. That is, I start R and load the Delphi DLL; then I use .C to call a Delphi routine which allocates a piece of memory X and returns to R a pointer to X; then I do some more stuff in R; then I call another Delphi

Hi, I have added heartbeat mode as global, but when I do a mkfs and mount, and then check the mount, it says I am in local mode. Even /sys/kernel/config/cluster/ocfs2/heartbeat/mode says local. I am running CentOS with 3.x kernel, with ocfs2-tools-1.6.4-1118. mkfs -t ocfs2 -b 4K -C 1M -N 16 --cluster-stack=o2cb /dev/sdb mount -t ocfs2 /dev/sdb /mnt -o

Hello, when looking at "Writing R Extensions" with mem-allocation in mind, I wondered, which functions to use to substitute malloc(), calloc(), realloc() and strdup() and free(). It looked like Calloc() or R_Calloc() might be useful for some of my tasks, but when trying to use R_Calloc() for example, I got some error messages which I don't see where they are coming from. Maybe I

I am trying to get our database interface (PADI) working with R. The code does some memory allocation and for Splus there is an ifdef which controls whether malloc or S_alloc is called. I did nm R.binary | grep alloc to see if this was supported and I find there are some choices: [2490] | 446036| 272|FUNC |GLOB |0 |7 |R_alloc [806] | 693956| 312|FUNC |LOCL |0 |7

I would like to retrieve a vector of integers from a call to .C(), but I don't know its length in advance. How do I do this without making an ugly safe guess? My vector is called "sequences". I am passing the argument sequences = integer(0) in the call to .C(), then declaring the corresponding argument as int *sequences in my C code. I tried R_alloc()ing the storage in C and

Hi, I am trying to implement an algorithm in C which will be called via the .Call() interface. While reading the 'Writing R Extension' manual, I stumbled upon the R_alloc() function for allocating storage for C objects. The manual says it should be used to allocate storage if an C object is needed/created while manipulating R objects within a function called via the .Call() interface.

Hi, Could someone please point to an example of passing strings from .C() calls back to R? I want to be able to do something like this: str <- .C("return_foo_string", str=character(1))$str void return_foo_string(char ** str) { *str = "foo"; } The above code has at least two memory allocation "concerns": 1) How to properly allocate "foo". I

I am calling a C (C++ really) function via the .C interface. Sometimes when things go wrong I want to return an error message. 1. R provides C functions error and warning which look about right. But exactly how does this exit, and in particular what happens with cleaning up, calling C++ destructors, and unwinding the stack? Will I get memory leaks? 2. Before I discovered those functions, I

Hello, what happens, when a function (R-extension in C), that allocated memory (strdup(), malloc()/calloc() and so on), and is used in interactive mode, then will be stopped via Ctrl-C? I would assume that there remains allocated memory, which is not usable and also not accessable (hence no way to free it). Are there any mechanisms in R that could help in rolling back the allocation? Normally

I have some compiled code that works under winXp but not under linux (kernel 2.6.10-5). I'm also using R 2.1.0 After debugging, I've discovered that in this code: #define NMAX 256 long **box; ... box = (long **)R_alloc(NMAX, sizeof(long *)); //<---HERE THE SIGSEGV for (i=0; i<NMAX; i++) box[i] = (long *) R_alloc(NMAX, sizeof(long)); inside the *first* call to the

Hi, As was discussed earlier in another thread and as documented in R-exts .Call() should not be interruptible by Ctrl-C. However the following code, which spends most of its time inside mkChar, turned out to be interruptible on RH-7.3 R-1.8.1 gcc-2.96: #include <Rinternals.h> #include <R.h> SEXP foo0(const SEXP nSexp) { int i, n; SEXP resSexp; if (!isInteger(nSexp))

I have some compiled code that works under winXp but not under linux (kernel 2.6.10-5). I'm also using R 2.1.0 After debugging, I've discovered that this code: #define NMAX 256 long **box; ... box = (long **)R_alloc(NMAX, sizeof(long *)); gives a null pointer, so subsequent line: for (i=0; i<NMAX; i++) box[i] = (long *) R_alloc(NMAX, sizeof(long)); gives a SIGSEGV signal.

I am trying to write a C function to create a vector of integers that can be used by the R calling function. I do not know the size of the vector in the R calling function. (Well, actually, I have an upper limit on the size, but that is so large that R cannot allocate it. What I'm doing in the function is to do a sieving procedure, and the result will be small enough to fit into my

Hi, A recent discussion on the list about tryCatch and signals made me think about memory allocation and signals in C extension modules. What happens to the memory allocated by R_alloc and Calloc if the user pressed Ctr-C during the call? R-ext doesn't seem to discuss this. I'd guess that R_alloc is interrupt-safe while Calloc is not, but I am not sure. In any case a paragraph in R-ext

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 R-devel, Some time ago I started a thread that boiled down to clean-up actions after non-local exits in R, see below. I wonder if there has been any progress on this? R-ext 2.6.1 doesn't say much on the subject. How, for example, do people deal with a situation where their C (C++) function opens a file and then receives a signal or longjump-s on error(), how do they make sure the

I am calling 'vmmin' several times from a C function (which is called via .C). It works very well, except for memory consumption. The cause is that vmmin allocates memory via R_alloc, and this memory is not freed as vmmin exits. Instead all the allocated memory is freed on return of the .C call. In one application, I have 2000 functions of 500 variables each to minimize. In each call to

Hi, all. I've got some C code that I've used successfully, and fairly extensively, in R-1.1.1, which is suddenly causing segmentation faults in R-1.2.0. The original code used calloc (just plain calloc) with a free at the end, but I've tried replacing the calloc with R_alloc (based on the Writing R extensions documentation, which I'm not sure I've understood properly), and

Dear list I have two (trivial) memory-questions related to a call with .C: If I allocate memory with R_alloc in a C-program (called with .C), will that memory "be taken from" the "available memory pool" (of a maximum of 4gb?) which R can allocate? (This is the impression I get from "Writing R extensions".) If instead I use malloc; will that memory then be taken

I want to write a little stand-alone C program that calls R_alloc, but I get a segmentation fault: int main(int argc, char** argv){ double* d = (double *)R_alloc(2, sizeof(double)); // <- segmentation fault! return 0; } gdb reveals that sizeof(double) evaluated to 0: > R_alloc (nelem=2, eltsize=0) at memory.c:1649 so it results in the segfault later. This is how I compile my