Hello to everyone!
I use .Call to call a C function without arguments wich calls a
fortran optimization package. My C function uses others C and Fortran
functions and it works fine when I call it from a main() in a C
program. But when I call it from R with
.Call("name_of_the_c_function"), R gives me some weird output.
This weird output is a worng answer to my optimization problem
(sometimes after thousands iteractions, what does not occur when
called from C) or a segmentation fault error. The kind of output
depends on the machine I am using. At home I got a segmentation faul,
in university I got those wrong values.
I tried a memcheck in C and Fortran binaries, but everything seems
allright except by 2 missing free() calls (wich I don`t think might be
causing this error).
I compiled my C and Fortran files with R CMD SHARED and then linked
all the .o with the same command. I also tried compiling all the
needed object files with -fPIC and -shared and then using R CMD SHARED
to link everything, but I got the same problem.
The only thing I do in R is the following:
dyn.load("mylib.so")
.Call("name_of_the_c_function")
Can someone hellp me with this?
Thanks!
Ricardo
Hello to everyone!
I use .Call to call a C function without arguments wich calls a
fortran optimization package. My C function uses others C and Fortran
functions and it works fine when I call it from a main() in a C
program. But when I call it from R with
.Call("name_of_the_c_function"), R gives me some weird output.
This weird output is a worng answer to my optimization problem
(sometimes after thousands iteractions, what does not occur when
called from C) or a segmentation fault error. The kind of output
depends on the machine I am using. At home I got a segmentation faul,
in university I got those wrong values.
I tried a memcheck in C and Fortran binaries, but everything seems
allright except by 2 missing free() calls (wich I don`t think might be
causing this error).
I compiled my C and Fortran files with R CMD SHARED and then linked
all the .o with the same command. I also tried compiling all the
needed object files with -fPIC and -shared and then using R CMD SHARED
to link everything, but I got the same problem.
The only thing I do in R is the following:
dyn.load("mylib.so")
.Call("name_of_the_c_function")
Can someone hellp me with this?
Thanks!
Ricardo
Hi Simon!
You are right!
Ok, here it is (a little resumed):
#include <stdio.h>
#include <math.h>
#include <time.h>
#include <sys/times.h>
#include "interface.h"
SEXP main() {
int gtype, inform, m, n, maxoutit, maxtotit, maxtotfc, outiter,
totcgcnt, totfcnt, totgcnt, totiter, iprint, ncomp, i;
double f,nalpsupn,epsfeas,epsopt,snorm;
int *wi;
int *equatn, *linear;
double *l, *lambda, *rho, *u, *wd1, *wd2, *wd3, *wd4, *wd5, *wd6,
*wd7, *wd8, *wd9, *wd10, *wd11, *wd12, *wd13, *x;
FILE *fileOutput;
clock_t clock;
double time;
struct tms buffer;
/* SOME LINES TO SET UP PROBLEM DATA */
/* SOME LINES TO MEMORY ALLOCATION */
/* SOME LINES TO SET SOME ALGENCAN ARGUMENTS */
/* TRANSFORMS THE TYPE INT OF C IN THE TYPE LOGICAL OF FORTRAN
* FOR THE ARRAYS equatn AND linear */
C2FLOGICALV(equatn, m);
C2FLOGICALV(linear, m);
clock = times(&buffer);
/* CALL OPTIMIZATION PACKAGE */
fortran_optimization_package (n, x, l, u, m, lambda, rho, equatn, linear,
epsfeas,
epsopt, maxoutit, maxtotfc, maxtotit, iprint, ncomp, gtype,
f, snorm, nalpsupn, outiter, totiter, totfcnt, totgcnt,
totcgcnt, inform, wi, wd1, wd2, wd3, wd4, wd5, wd6, wd7,
wd8, wd9, wd10, wd11, wd12, wd13)
return R_NilValue
}
All the variables passed to fortran_optimization_package are allocated an
initialized correctly, that's why I resumed those lines with a comment.
Thanks,
Ricardo
> You still didn't even supply your declaration of the function
you're
> calling, so there is not much we can help you with. Hopefully your
> function looks like this:
>
> #include <R.h>
> #include <Rinternals.h>
>
> SEXP foo() {
>
> [... you code goes here..]
>
> return R_NilValue;
> }
>
> If you're constructing the returned object then you should consider
> posting the whole code, because you're likely making a mistake
> somewhere in that part.
>
> Cheers,
> Simon
>
>
[[alternative HTML version deleted]]
I suggest you look at the code for .Call() in dotcode.c. I suspect the problem is in dealing with R objects, however. You don't show how you get from SEXPs to pointers to pass to Fortran, or what the Fortran routine requires. I don't understand how you can call the "same" function from C. How do you deal with SEXPs? Reid Huntsinger Reid Huntsinger -----Original Message----- From: r-devel-bounces at r-project.org [mailto:r-devel-bounces at r-project.org] On Behalf Of Ricardo Luiz Andrade Abrantes Sent: Tuesday, August 30, 2005 4:33 PM To: r-devel at r-project.org Subject: Re: [Rd] .Call and Segmentation Fault Hello to everybody! After reading all the C code, checking for problems, and find nothing, I decided something a little bit different... If my ".so" library works in a wrog way in R it should do the same in C. So I created a C program that loads my library file and the executes the same function R is executing. The program worked perfectly! In fact I changed two things in my library: The function I call now return an int, not a SEXP, and the return value is 0 not R_NilValue. Valgrind's output is ok too... If .Call has no problems, and if my function works perfect when called from a C program, where the problem lies? Why my program becomes "crazy" when I run it from R? I would apreciate very much your help! I don't where else I could find help on this. I can provide any piece of code that may help, Its just ask! Thanks, Ricardo On 8/28/05, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:> > On Sat, 27 Aug 2005, Ricardo Luiz Andrade Abrantes wrote: > > > Hi! > > Yes, I am returning a SEXP from the functions called from R, and the > > problem occurs before (thousands of iterations before) the return > > point. > > In fact I runned valgrind into R and when I call ".Call(...) " I got > > many errors like: > > ==4324== Use of uninitialised value of size 8 > > ==4324== at 0x1CB0766D: tnls_ (gencan.f:4101) > > ==4324== by 0x1CB01962: gencan_ (gencan.f:1876) > > ==4324== by 0x1CAFECA5: easygencan_ (gencan.f:440) > > ==4324== by 0x1CB0B47D: algencan_ (algencan.f:517) > > ==4324== by 0x1CB09E74: easyalgencan_ (algencan.f:76) > > ==4324== by 0x1CAFE5B3: main (algencanma.c:808) > > what does not happens when I compile the algencanma as a regular > > program (not a library) and run it from shell. Valgrind does not find > > anything wrong when I run the program directly, except 2 missing > > free() calls. > > Do you have any ideas where the problem lies (R .Call function or C > program)? > > It cannot be .Call: your .Call passed no parameters so there was nothing > to be uninitialized. I did ask you why you were doing that. > > .Call is very heavily tested in lots of R applications, so the prior > probability of innocence must be very high. > > -- > 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 >[[alternative HTML version deleted]] ______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel