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
.Call and Segmentation Fault
8 messages · Ricardo Luiz Andrade Abrantes, Byron Ellis, Brian Ripley +2 more
Are you returning a SEXP? .Call (unlike .C) expects a SEXP return value. It sounds like you're returning garbage and R is choking on that when it tries to use the address as a SEXP.
On Aug 26, 2005, at 3:19 PM, Ricardo Luiz Andrade Abrantes wrote:
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
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
--- Byron Ellis (ellis at stat.harvard.edu) "Oook" -- The Librarian
1 day later
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)?
By the way I am using a debian linux with kernel 2.6.
Thanks
Ricardo
On 8/26/05, Byron Ellis <ellis at stat.harvard.edu> wrote:
Are you returning a SEXP? .Call (unlike .C) expects a SEXP return value. It sounds like you're returning garbage and R is choking on that when it tries to use the address as a SEXP. On Aug 26, 2005, at 3:19 PM, Ricardo Luiz Andrade Abrantes wrote:
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
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
--- Byron Ellis (ellis at stat.harvard.edu) "Oook" -- The Librarian
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
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.
This .Call without parameters is just for a test. I am constructing an interface to this C/Fortran optimization package, and because this segmentation fault problem, I decided to modify the interface for a simple test: call a C function that initialize the set of variables wich describe the problem to be solved (wich supose to be done in R) and call the optimization package. But my surprise was that the program when called from R gives me the same segmentation fault error. But when I compile the program as a regular linux binary and run it from shell I don't get any problem. That's why I thought it could be a problem with .Call.
.Call is very heavily tested in lots of R applications, so the prior probability of innocence must be very high.
Thanks professor, I will check the C program again. Ricardo
-- 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
2 days later
An embedded and charset-unspecified text was scrubbed... Name: not available Url: https://stat.ethz.ch/pipermail/r-devel/attachments/20050830/fb37fcb4/attachment.pl
Ricardo Luiz Andrade Abrantes <rabrantes82 at gmail.com> writes:
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.
Well, did you try running under a debugger? R -d gdb then "bt" after the segfault. (Make sure that things are compiled with -g option)
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 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907
On Tue, 31 Aug 2005, Peter Dalgaard wrote:
Well, did you try running under a debugger? R -d gdb then "bt" after the segfault. (Make sure that things are compiled with -g option)
It would also be worth renaming the the function -- while I don't see exactly how it could be causing the problem, I would be nervous about having a C function called main() that wasn't the real main(). -thomas