Hello there!
I almost don't deal with SEXPs. The function's name is main() it returns a
SEXP wich is R_NilValue, thats all I use of SEXPs. This function call an
optimization packge and the output goes all to a text file.
Well, I followed Mr. Lumley's hint and used gdb with R and my program.
Together with a friend we could find the problem.
Inside the Fortran optimization package there's a subroutine called cg(...),
and for some wierd reason this subroutine is never called (so, some
variables are not correctly initialized) and the program becomes crazy.
I did this small example to show you what happens:
File: prog.f
-------------
subroutine cg()
write(*,*) 'Just a simple test'
end
subroutine program()
write(*,*) 'Calling the function...'
call cg()
end
File test.h
------------
#include "cfortran.h"
PROTOCCALLSFSUB0(PROGRAM,program)
#define program() CCALLSFSUB0(PROGRAM,program)
File test.c
------------
#include <R.h>
#include <Rdefines.h>
#include <stdio.h>
#include "test.h"
SEXP simple_program(){
program();
return R_NilValue;
}
I compile the C and Fortran souces into a shared lib. I open R, do a
dyn.load("lib's name") and then a .Call("simple_program").
What I got?
Calling the function...
Segmentation fault
What if I change the cg function's name to pp? My Fortran code is now:
File: prog.f
-------------
subroutine pp()
write(*,*) 'Just a simple test'
end
subroutine program()
write(*,*) 'Calling the function...'
call pp()
end
And the output from R is:
Calling the function...
Just a simple test
NULL
Can anyone explain this? Is there a way to solve it? The optimization
package I use has the "cg" function, and I cannot change it's name!
Thanks,
Ricardo
On 8/31/05, Huntsinger, Reid <[EMAIL PROTECTED]> wrote:
>
> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Ricardo Luiz Andrade Abrantes
> Sent: Tuesday, August 30, 2005 4:33 PM
> To: r-devel@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 <[EMAIL PROTECTED]> wrote:
> >
> > On Sat, 27> dyn.load("libtest.so")
> > .Call("simple_program")
> Calling the function...
> Falha de segmentação
> 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, [EMAIL PROTECTED]
> > 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@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Notice: This e-mail message, together with any attachments...{{dropped}}
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
