similar to: When exactly do I need R_alloc when using the .Call() interface?

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

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

Dear All, In a package, I want to use some C code where I am using a structure (as the basic element of a linked list) with flexible array members. Basically, this is a structure where the last component is an incomplete array type (e.g., Harbison & Steel, "C, a reference manual, 5th ed.", p. 159) such as: struct Sequence { struct Sequence *next; int len; unsigned int

Full_Name: Wolfgang Huber Version: R-devel_2005-03-10 OS: alphaev68-dec-osf4.0f Submission from: (NULL) (62.253.128.15) This report concerns allocation of large (>2^31 byte) chunks of memory with R_alloc. I suspect it is a bug/typo but please don't hate me if it's actually a feature: In R, I can happily create large matrices: > a= matrix(0, nrow=191481, ncol=3063) > dim(a) [1]

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

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.

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

Full_Name: Dan Kelley Version: 2.2.1 OS: Mac OSX Submission from: (NULL) (129.173.23.36) I'm having difficulties getting R_alloc() to work on a 64-bit Mac running R 2.2.1 installed via a .dmg file obtained from the R site. Details are given below, in a level of detail that I hope is appropriate. My eye was particularly drawn to line #2 in the gdb 'where' output, but line #1 seems

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

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

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

Dear R-devel, While tracking down some hard-to-reproduce bugs in a package I maintain, I stumbled on a behavior change between R 2.15.0 and the current R-devel (or SVN trunk). In 2.15.0 and earlier, if you passed an 0-length vector of the right mode (e.g., double(0) or integer(0)) as one of the arguments in a .C() call with DUP=TRUE (the default), the C routine would be passed NULL (the C

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

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 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

For example, the following changes are necessary when i convert a Japanese hiragana into katakana in chattr. R code: > chartr("\u3041-\u3093","\u30a1-\u30f3","\u3084\u3063\u305f\u30fc") --- R-alpha.orig/src/main/character.c 2007-09-05 07:13:27.000000000 +0900 +++ R-alpha/src/main/character.c 2007-09-13 16:10:21.000000000 +0900 @@ -2041,6 +2041,16 @@

Hello. I'm having difficulties getting R_alloc() to work. The test platform is a 64-bit Mac running R 2.2.1 installed via a .dmg file obtained from the R site. Details are given below, in a level of detail that I hope is appropriate. My eye was particularly drawn to line #2 in the gdb 'where' output, but line #1 seems sensible so I may just be displaying my ignorance by

According to the "R Internals" document, for a custom device, I should create a pDevDesc structure that gets passed to GECreateDevDesc. ..elided... pDevDesc dev; /* Allocate and initialize the device driver data */ if (!(dev = (pDevDesc) calloc(1, sizeof(DevDesc)))) return 0; /* or error() */ /* set up device driver or free ?dev? and error() */ gdd = GEcreateDevDesc(dev);

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))