R devel - Jan 2008 - R_alloc segfaults

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

You can't call arbitrary R entry points from a standalone C program 
without initializing R -- you have not intialized the memory allocator 
here.

See 'Writing R Extensions' for various ways to embed R in your own 
program.

On Sat, 19 Jan 2008, Markus wrote:
> 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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595