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 program:
$ cd R-2.6.1/src/main
$ gcc -std=gnu99 -I../../src/extra/zlib -I../../src/extra/bzip2
-I../../src/extra/pcre -I. -I../../src/include -I../../src/include
-I/usr/local/include -DHAVE_CONFIG_H -g -c main.c -o main.o
$ gcc -std=gnu99 -Wl,--export-dynamic [lots of R .o and .a files]
-lreadline -lncurses -ldl -lm
What could cause this strange memory problem? Is the compile command wrong/
I'd be happy to just call malloc instead of R_alloc, but what I
actually want to do is to call lbfgsb (see optim.c), and that uses
R_alloc. When I do call lbfgsb from my stand-alone C program, its
R_alloc call is evaluated with these arguments
> R_alloc (nelem=1, eltsize=-1073870176) at memory.c:1649
and I get a segfault again. When I modify the original optim.c to use
malloc instead of R_alloc, I get the segfault a little later when it
calls S_alloc. So I'd like to fix the R_alloc/S_alloc problem, rather
than modifying the whole optim.c code.
Any hints how I can fix the R_alloc calls and avoid the segmentation faults?
Thanks!
Markus
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
