thr3ads.net - R devel - [Rd] .Fortran interface error [Apr 2010]

If this information is useful, please help other people find it:
Share via:

jgarcia at ija.csic.es

2010-Apr-13 10:42 UTC

[Rd] .Fortran interface error

Hi all,
I'm preparing a package which uses .Fortran to interface a Fortran 95
function. This F95 function simply receives the name of a file from R,
opens this file and forwards its content to a F95 module, which, in turn,
makes the real computation.  The F95 module is a pre-existing one and I'm
trying to use it in its actual state.

Thus, data transfer between R and this F95 module is made through scratch
system files (binary or ASCII), and R-F95 interface simply forwards a
pathed name to this module.

OS: openSUSE 10.3 (x86_64)
R version 2.10.1 (2009-12-14)

Then, I've put a demo which makes use of the function, but after model
execution (the F95 code) finishes correctly, and all output is read  back
properly by R (again through system files), R halts, and the following
message appears:

*** glibc detected *** /usr/local/lib64/R/bin/exec/R: free(): invalid
pointer: 0x00000000008a1aa0 ***

Could you give me any hint about where to look for errors?

Just to say that if instead of the R-f95 interface,

I compile the F95 code as executable "runhydro" an call it as:
>system(paste(bindirp,"runhydro",sep="/"))
everything is OK, while compilation as a dynamic library and access to the
F95 "big" module through the simple R-F95 interface:
>res <- .Fortran("runhydro",                 runfile = as.character(mainfile[1]),
                 charsfile = nchar(mainfile[1]),
                 PACKAGE = "hydroarid"
               )

is what is giving the error (I could handle you the package)

Thanks and best regards,

Javier
---

Prof Brian Ripley

2010-Apr-13 11:15 UTC

head link

[Rd] .Fortran interface error

Please try running this under valgrind (see 'Writing R Extensions'). 
The most likely cause is that the Fortran code is corrupting its or 
R's memory.  You may need a build of R set up to instrument R 
allocations (see the manual for details).

On Tue, 13 Apr 2010, jgarcia at ija.csic.es wrote:
> Hi all,
> I'm preparing a package which uses .Fortran to interface a Fortran 95
> function. This F95 function simply receives the name of a file from R,
> opens this file and forwards its content to a F95 module, which, in turn,
> makes the real computation.  The F95 module is a pre-existing one and
I'm
> trying to use it in its actual state.
>
> Thus, data transfer between R and this F95 module is made through scratch
> system files (binary or ASCII), and R-F95 interface simply forwards a
> pathed name to this module.
>
> OS: openSUSE 10.3 (x86_64)
> R version 2.10.1 (2009-12-14)
>
> Then, I've put a demo which makes use of the function, but after model
> execution (the F95 code) finishes correctly, and all output is read  back
> properly by R (again through system files), R halts, and the following
> message appears:
>
> *** glibc detected *** /usr/local/lib64/R/bin/exec/R: free(): invalid
> pointer: 0x00000000008a1aa0 ***
>
> Could you give me any hint about where to look for errors?
>
> Just to say that if instead of the R-f95 interface,
>
> I compile the F95 code as executable "runhydro" an call it as:
>
>> system(paste(bindirp,"runhydro",sep="/"))
>
> everything is OK, while compilation as a dynamic library and access to the
> F95 "big" module through the simple R-F95 interface:
>
>> res <- .Fortran("runhydro",
>                 runfile = as.character(mainfile[1]),
>                 charsfile = nchar(mainfile[1]),
>                 PACKAGE = "hydroarid"
>               )
>
> is what is giving the error (I could handle you the package)
>
> Thanks and best regards,
>
> Javier
> ---
>
> ______________________________________________
> 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

jgarcia at ija.csic.es

2010-Apr-13 20:20 UTC

head link

[Rd] .Fortran interface error

Yes!!!!!!!! That's it! Thanks a lot!!!!!!
Changing UNIT=5 in the F95 code by UNIT=7 solves the collision.

Thank you very much Charlie, I've spent a lot of hours with this.

Still

R -d valgrind --vanilla < foofortran.Rcheck/foofortran-Ex.R

gives 3 errors (two "Invalid read of size 8" and one "Syscall
param
write(buf) points to uninitialised byte(s)"), which are the same it gave
with UNIT=5. However, everything seems to work fine now in the normal
execution :-)

Thank you very much again

Javier
---

==25824== Memcheck, a memory error detector.
==25824== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==25824== Using LibVEX rev 1732, a library for dynamic binary translation.
==25824== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==25824== Using valgrind-3.2.3, a dynamic binary instrumentation framework.
==25824== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==25824== For more details, rerun with: -v
==25824=
R version 2.10.1 (2009-12-14)
Copyright (C) 2009 The R Foundation for Statistical Computing
ISBN 3-900051-07-0

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> pkgname <- "foofortran"
> source(file.path(R.home("share"), "R",
"examples-header.R"))
> options(warn = 1)
> library('foofortran')==25824== Invalid read of size 8
==25824==    at 0x401431B: (within /lib64/ld-2.6.1.so)
==25824==    by 0x4009631: (within /lib64/ld-2.6.1.so)
==25824==    by 0x5A9D804: (within /lib64/libc-2.6.1.so)
==25824==    by 0x57A3143: (within /lib64/libdl-2.6.1.so)
==25824==    by 0x400C8E5: (within /lib64/ld-2.6.1.so)
==25824==    by 0x57A336C: (within /lib64/libdl-2.6.1.so)
==25824==    by 0x57A30F9: dlsym (in /lib64/libdl-2.6.1.so)
==25824==    by 0x59871C: R_local_dlsym (dynload.c:216)
==25824==    by 0x4C9944: AddDLL (Rdynload.c:557)
==25824==    by 0x4CA073: do_dynload (Rdynload.c:893)
==25824==    by 0x428372: do_internal (names.c:1165)
==25824==    by 0x54D1E1: Rf_eval (eval.c:464)
==25824==  Address 0x61BA068 is 16 bytes inside a block of size 18 alloc'd
==25824==    at 0x4C21D06: malloc (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==25824==    by 0x4C9918: AddDLL (Rdynload.c:549)
==25824==    by 0x4CA073: do_dynload (Rdynload.c:893)
==25824==    by 0x428372: do_internal (names.c:1165)
==25824==    by 0x54D1E1: Rf_eval (eval.c:464)
==25824==    by 0x54F6AF: Rf_applyClosure (eval.c:699)
==25824==    by 0x54D105: Rf_eval (eval.c:508)
==25824==    by 0x54D1E1: Rf_eval (eval.c:464)
==25824==    by 0x54EE71: do_set (eval.c:1502)
==25824==    by 0x54D1E1: Rf_eval (eval.c:464)
==25824==    by 0x55157B: do_begin (eval.c:1245)
==25824==    by 0x54D1E1: Rf_eval (eval.c:464)
==25824===25824== Invalid read of size 8
==25824==    at 0x4014DCE: (within /lib64/ld-2.6.1.so)
==25824==    by 0x400967A: (within /lib64/ld-2.6.1.so)
==25824==    by 0x5A9D804: (within /lib64/libc-2.6.1.so)
==25824==    by 0x57A3143: (within /lib64/libdl-2.6.1.so)
==25824==    by 0x400C8E5: (within /lib64/ld-2.6.1.so)
==25824==    by 0x57A336C: (within /lib64/libdl-2.6.1.so)
==25824==    by 0x57A30F9: dlsym (in /lib64/libdl-2.6.1.so)
==25824==    by 0x59871C: R_local_dlsym (dynload.c:216)
==25824==    by 0x4C9944: AddDLL (Rdynload.c:557)
==25824==    by 0x4CA073: do_dynload (Rdynload.c:893)
==25824==    by 0x428372: do_internal (names.c:1165)
==25824==    by 0x54D1E1: Rf_eval (eval.c:464)
==25824==  Address 0x61BA068 is 16 bytes inside a block of size 18 alloc'd
==25824==    at 0x4C21D06: malloc (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==25824==    by 0x4C9918: AddDLL (Rdynload.c:549)
==25824==    by 0x4CA073: do_dynload (Rdynload.c:893)
==25824==    by 0x428372: do_internal (names.c:1165)
==25824==    by 0x54D1E1: Rf_eval (eval.c:464)
==25824==    by 0x54F6AF: Rf_applyClosure (eval.c:699)
==25824==    by 0x54D105: Rf_eval (eval.c:508)
==25824==    by 0x54D1E1: Rf_eval (eval.c:464)
==25824==    by 0x54EE71: do_set (eval.c:1502)
==25824==    by 0x54D1E1: Rf_eval (eval.c:464)
==25824==    by 0x55157B: do_begin (eval.c:1245)
==25824==    by 0x54D1E1: Rf_eval (eval.c:464)>
> assign(".oldSearch", search(), pos = 'CheckExEnv')
> cleanEx()
> nameEx("fooRf90")
> ### * fooRf90
>
> flush(stderr()); flush(stdout())
>
> ### Name: fooRf90
> ### Title: Sample Call to FORTRAN 90
> ### Aliases: fooRf90
>
> ### ** Examples
>
> x <- c(1:10)
> filename <- "anystring"
> res <- fooRf90(x, filename)==25824===25824== Syscall param write(buf) points to uninitialised byte(s)
==25824==    at 0x5A5DC40: write (in /lib64/libc-2.6.1.so)
==25824==    by 0x50E8000: (within /usr/lib64/libgfortran.so.2.0.0)
==25824==    by 0x50E807D: (within /usr/lib64/libgfortran.so.2.0.0)
==25824==    by 0x50E8817: (within /usr/lib64/libgfortran.so.2.0.0)
==25824==    by 0x50E545C: (within /usr/lib64/libgfortran.so.2.0.0)
==25824==    by 0x50E597B: (within /usr/lib64/libgfortran.so.2.0.0)
==25824==    by 0x50E59D8: _gfortran_st_write_done (in
/usr/lib64/libgfortran.so.2.0.0)
==25824==    by 0x849CC02: foof90_ (ofoofunc.f90:18)
==25824==    by 0x5200FD: do_dotCode (dotcode.c:1724)
==25824==    by 0x54D3AB: Rf_eval (eval.c:490)
==25824==    by 0x54EE71: do_set (eval.c:1502)
==25824==    by 0x54D1E1: Rf_eval (eval.c:464)
==25824==  Address 0x404C3D3 is 171 bytes inside a block of size 8,344
alloc'd
==25824==    at 0x4C21D06: malloc (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==25824==    by 0x5069D38: (within /usr/lib64/libgfortran.so.2.0.0)
==25824==    by 0x50E8269: (within /usr/lib64/libgfortran.so.2.0.0)
==25824==    by 0x50E7A73: (within /usr/lib64/libgfortran.so.2.0.0)
==25824==    by 0x5069B37: (within /usr/lib64/libgfortran.so.2.0.0)
==25824==    by 0x50F9241: (within /usr/lib64/libgfortran.so.2.0.0)
==25824==    by 0x5066CF2: (within /usr/lib64/libgfortran.so.2.0.0)
 runfile:   anystring
!"#$%&'&#65533;&#65533;&#65533;&#65533;06
                                  
&#65533;&#65533;&#65533;&#1075;&#65533;'


&#9618;&#9618;
orunfile:   anystring

>
> jgarcia-2 wrote:
>>
>> Hi,
>> I've stripped all the code, and it seems that any simple attempt to
>> open/close a file from fortran is the cause of the error, and the error
>> appears in f77 as well as in f95 code. Please, find attached a foo
>> package
>> that reproduce the errors, it should build/check/install without any
>> problem (it does in my computer). If the code
>>
>>  OPEN( UNIT=5, FILE=runfile, STATUS='OLD',
ACTION='READ', &
>>        IOSTAT=status)
>>  WRITE (*,*) 'status:   ', status
>>  IF ( status == 0 ) THEN
>>    READ(5,'(A)') modelsel
>>    READ(5,'(A)') modelfile
>>    READ(5,'(A)') datdirpid
>>    CLOSE(5)
>>
>>    WRITE (*,*) 'selected model:   ', modelsel
>>    WRITE (*,*) 'model input file: ', modelfile
>>    WRITE (*,*) 'datdirpid: ', datdirpid
>>  ELSE
>>    WRITE (*,1002) status
>>     1002 FORMAT (1X,'open runfile failed--status = ', I6)
>>    STOP
>>  END IF
>>
>> is commented out in any of the two sources files (the f77 or the f95
>> one),
>> none of the two corresponding wrappers (as they appear in the examples)
>> give an error. Thus it seems clear that the operation causing it is the
>> OPEN/CLOSE. Without commenting out these pieces of code, everything
>> seems
>> to work right but R halts after a call to the wrapper functions. I
>> cannot
>> find any comment about this in the documentation. Please, could you
tell
>> me if this is a known error?
>>
>> Thanks,
>>
>> Javier
>>
>
> It looks like you may have some I/O collisions occurring.  Some Fortran
> compilers treat unit 5 as being STDIN, so attempting to read from that
> stream when the Fortran program is embedded may be giving R a headache.  I
> would recommend either passing "modelsel", "modelfile"
and "datadirpid" as
> parameters from R, or reading from a file using a different unit number.
>
> For output, instead of using write(*,*) you may need to use some of the R
> output callbacks described in section 6.5.1 of "Writing R
Extensions".
>
> Hope this helps!
>
> -Charlie
>
>
>
> -----
> Charlie Sharpsteen
> Undergraduate-- Environmental Resources Engineering
> Humboldt State University
> --
> View this message in context:
> http://n4.nabble.com/Fortran-interface-error-tp1838225p1838888.html
> Sent from the R devel mailing list archive at Nabble.com.
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

Apparently Analagous Threads

Search for more possibly parallel threads

R devel - Apr 2010 - .Fortran interface error

[Rd] .Fortran interface error

[Rd] .Fortran interface error

[Rd] .Fortran interface error

Apparently Analagous Threads