Re: [Rd] .Call and Segmentation Fault
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
#include
#include
#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,
Re: [Rd] .Call and Segmentation Fault
Ricardo Luiz Andrade Abrantes <[EMAIL PROTECTED]> writes:
> 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
> #include
> #include
> #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!
H Did you ever tell us
1) Exactly what your platform is
2) How you generated the shared library (R CMD SHLIB, or?)
3) What you did to load it into R
?
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] .Call with C and Fortran together (PR#8122)
Full_Name: Ricardo Luiz de Andrade Abrantes
Version: 2.1.1
OS: Debian Linux, kernel 2.6.8
Submission from: (NULL) (201.6.83.153)
The problem can be well explained with the following example:
Suppose I made a program in fortran, and a C interfacece to it. Now I want to
use this C interface in R to call my fortran program. Then I modified my C file
to deal with SEXPs and compile it as a shared lib. Look at the files:
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
#include
#include
SEXP simple_program(){
program();
return R_NilValue;
}
I compile the C and Fortran souces into a shared lib, 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
In some machines I don't get the segmentation fault problem, but I don't get the
message "Just a simple test" either (when using "cg" as the subroutine's name).
I believe this is bug in R because if I change my C interface again to return a
0 instead of a R_NilValue, and then use it with another C program wich loads the
dynamic library amd call the function simple_program(), everything work
perfectly.
Thanks,
Ricardo
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] .Call and Segmentation Fault
I think I did.
But if I don't, (1) my OS is Linux (Debian) kernel 2.6.8, R version 2.1.1.
(2) I generate the shared lib with a cutom makefile:
FC = g77
CC = gcc
RC = R CMD SHLIB
CFLAGS = -Df2cFortran -I/usr/local/lib/R/include -I/usr/local/include -g3
-shared -fPIC
FFLAGS = -g3 -shared -fPIC
all: libtest
libtest: test.o prog.o
$(RC) test.o prog.o -o libtest.so
test.o: test.c test.h cfortran.h
$(CC) $(CFLAGS) -c test.c
prog.o: prog.f
$(FC) $(FFLAGS) -c prog.f
clean:
rm *.o *.so
(3) What I do in R is:
> dyn.load("libtest.so")
> .Call("simple_program")
Thanks,
Ricardo
On 04 Sep 2005 21:54:20 +0200, Peter Dalgaard <[EMAIL PROTECTED]>
wrote:
>
> Ricardo Luiz Andrade Abrantes <[EMAIL PROTECTED]> writes:
>
> > 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
> > #include
> > #include
> > #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!
>
> H Did you ever tell us
>
> 1) Exactly what your platform is
> 2) How you generated the shared library (R CMD SHLIB, or?)
> 3) What you did to load it into R
>
> ?
>
> --
> O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
> c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
> (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
> ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] A memory management question
On Sun, 4 Sep 2005, [EMAIL PROTECTED] wrote: > Can someone explain the use of SETLENGTH() and SETTRUELENGTH()? > > I would like to allocate a vector and reserve some space at the end, > so that it appears shorter than the allocated size. So that I can > more efficiently append to the vector, without requiring a new copy > every time. So I'd like to use SETLENGTH() with a shorter apparent > length, and bump this up as needed until I've used the entire space. > > There are only a couple users of SETLENGTH() in R, and they all appear > at first glance to be pointless: a few routines use allocVector() and > then call SETLENGTH() to set the vector length to the value that was > just allocated. What are valid uses for SETLENGTH()? And what are > the intended semantics for "truelength" as opposed to the regular > length? > This is not supported by the memory manager. Using SETLENGTH to change the length would confuse the garbage collector--we should probably remove SETLENGTH from the headers. TRUELENGTH is unused except for something very different in envir.c. Again we should probably remove or rename this to reflect how it is currently used. At one point, well before the current memory manager, I believe there was thought that we might allow this sort of over-allocation but I don't believe it was ever implemented. The memory manager does over-allocate small vectors by rounding up to convenient sizes, and the real size could be computed, but this is not true for large allocations--these correspond to malloc calls for the requested size--and in any case the memory manager relies on LENGTH giving the correct amount (maybe not heavily but this could change). > If GC happens and an object is moved, and its apparent LENGTH() > differs from its allocated length, does GC preserve the allocated > length, or the updated LENGTH()? Is there any way to get at the > original allocated length, given an SEXP? A GC does not move objects. Using R level vectors for the purpose you describe is in any case tricky since it is hard to reliably prevent copying. You are better off using something like an external pointer into an R-allocated object that is only accessible through the external pointer. Then you can manage the filled length yourself. luke -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: [EMAIL PROTECTED] Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Writing R-extensions
On Sat, 27 Aug 2005, Prof Brian Ripley wrote: > On Sat, 27 Aug 2005, Berwin A Turlach wrote: ... >> 3) The final sentence in the section on `Registering S3 methods' is: >> >>Any methods for a generic defined in a package that does not >>use a name space should be exported, and the package defining >>and exporting the method should be attached to the search path >>if the methods are to be found. >> >> I wonder whether this should actually be: >> >>Any methods for a generic defined in a package that does not >>use a name space should be exported, and the package defining >>and exporting the generic should be attached to the search path >> ^^^ >>if the methods are to be found. >> >> Or is the implication of that sentence that if I have a package >> with a name space which defines a method for a generic defined in >> another package that does not use a name space, then this method >> is only found if my package is attached to the search path and >> mere loading of the namespace is not sufficient? > There is no typo here and your reading in the paragraph above is correct. Best, luke > I think we need to check with the author (Luke, r23430). If the generic > is not visible there is no dispatch and so this would be irrelevant. > Assuming a typo, your implication is what the svn log entry says and how I > read the text. > > r23430 | luke | 2003-03-02 18:52:13 + (Sun, 02 Mar 2003) | 3 lines > > Added wording to clarify that S3method registration should only be used if > the generic is defined in a work space. > name? ... -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: [EMAIL PROTECTED] Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Writing R-extensions
G'day Luke, > "LT" == Luke Tierney <[EMAIL PROTECTED]> writes: >> On Sat, 27 Aug 2005, Berwin A Turlach wrote: >>> 3) The final sentence in the section on `Registering S3 >>> methods' is: >>> >>> Any methods for a generic defined in a package that does not >>> use a name space should be exported, and the package defining >>> and exporting the method should be attached to the search path >>> if the methods are to be found. >>> >>> [...] is the implication of that sentence that if I have a >>> package with a name space which defines a method for a generic >>> defined in another package that does not use a name space, >>> then this method is only found if my package is attached to >>> the search path and mere loading of the namespace is not >>> sufficient? LT> There is no typo here and your reading in the paragraph above LT> is correct. Thanks for the clarification. May I suggest that nevertheless there is a typo in this sentence and it should be " the package defining and exporting the methods..."? One reason why this sentence had me puzzled was that it uses twice "methods" and once "method". :) Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
