Grokbase Groups R r-devel March 2011
FAQ
Howdy,

I am having a problem with a library compiled from some legacy fortran
code. I can call the library, it runs as it should, returns a list,
and gives a ">" prompt, but then locks up the R session. Functions
typed in return nothing. ctrl-c results in a new prompt that is still
locked up, and R overwhelms the processor. This happens on Mac,
Windows, and Linux exactly the same. I close all open files and
confirm nothing is still open with unix lsof. I also have added a
routine to deallocate all allocated variables.

Does anyone have any suggestions in how I might be able to debug this
further? I have included output from the R session, top -o CPU, and R
CMD INSTALL below.

Thanks for your time on my behalf!
dan

Ouput from R session with library "swat" and subroutine "junk":
library.dynam("swat","EcoHydrology")
.Fortran("junk")
SWAT2005
Soil & Water Assessment Tool
PC Version
Program reading from file.cio . . . executing

list()
>
^C
q("n") ^C
obejcts()

^C
q() ^C
^Z
[1]+ Stopped r
DRF28:~/cornell/ecohydrology/swat_example/SJ_R_test_mac/Scenarios/Default/TxtInOut_R
dan$ killall R
[1]+ Terminated r


Output from top during lockup:
PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE
40750 R 96.6% 1:56.07 1 17 87 15M 1384K- 19M 49M

Output from R CMD INSTALL:
114 mirage5:fuka% R CMD INSTALL EcoHydrology
* installing to library
?/glade/home/fuka/R/x86_64-unknown-linux-gnu-library/2.12?
* installing *source* package ?EcoHydrology? ...
** libs
** arch -
Makefile:123: warning: overriding commands for target `.f.o'
/fs/local/apps/R-2.12.1/lib64/R/etc/Makeconf:132: warning: ignoring
old commands for target `.f.o'
gfortran -fPIC -g -O2 -c modparm.f
gfortran -fPIC -g -O2 -c addh.f
---SNIP successful gfortran output----
gfortran -fPIC -g -O2 -c zeroini.f
gfortran -fPIC -g -O2 -c closefiles.f
gfortran -shared -o swat.so modparm.o addh.o albedo.o
allocate_parms.o alph.o analyse.o anfert.o apex_day.o apply.o ascrv.o
---SNIP successful link output----
writeaa.o writed.o writem.o writeswatfile.o writeswatmain.o xisquare.o
xiunc.o xmon.o ysed.o zero0.o zero1.o zero2.o zeroini.o closefiles.o
installing to /glade/home/fuka/R/x86_64-unknown-linux-gnu-library/2.12/EcoHydrology/libs
** R
** data
** preparing package for lazy loading
** help
*** installing help indices
** building package indices ...
** testing if installed package can be loaded

* DONE (EcoHydrology)

Search Discussions

  • Duncan Murdoch at Mar 25, 2011 at 12:41 pm

    On 24/03/2011 12:35 PM, Daniel Fuka wrote:
    Howdy,

    I am having a problem with a library compiled from some legacy fortran
    code. I can call the library, it runs as it should, returns a list,
    and gives a ">" prompt, but then locks up the R session. Functions
    typed in return nothing. ctrl-c results in a new prompt that is still
    locked up, and R overwhelms the processor. This happens on Mac,
    Windows, and Linux exactly the same. I close all open files and
    confirm nothing is still open with unix lsof. I also have added a
    routine to deallocate all allocated variables.

    Does anyone have any suggestions in how I might be able to debug this
    further? I have included output from the R session, top -o CPU, and R
    CMD INSTALL below.
    I would guess that the Fortran is trying to do some Fortran-style I/O;
    that often causes problems. See Writing R Extensions for alternatives
    (dblepr etc.). Or it might be some other bug.

    The best way to debug something like this is with gdb or gdb plus a
    front end like Insight, Xcode, Eclipse, etc., but if you haven't used
    them before, they are somewhat daunting. If you're doing this on
    Windows you'll need to rebuild your library with the environment
    variable DEBUG set to T to get the debugging information compiled into
    it. Not sure if you need to do anything on the other systems.

    Duncan Murdoch
    Thanks for your time on my behalf!
    dan

    Ouput from R session with library "swat" and subroutine "junk":
    library.dynam("swat","EcoHydrology")
    .Fortran("junk")
    SWAT2005
    Soil& Water Assessment Tool
    PC Version
    Program reading from file.cio . . . executing

    list()
    ^C
    q("n") ^C
    obejcts()

    ^C
    q() ^C
    ^Z
    [1]+ Stopped r
    DRF28:~/cornell/ecohydrology/swat_example/SJ_R_test_mac/Scenarios/Default/TxtInOut_R
    dan$ killall R
    [1]+ Terminated r


    Output from top during lockup:
    PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE
    40750 R 96.6% 1:56.07 1 17 87 15M 1384K- 19M 49M

    Output from R CMD INSTALL:
    114 mirage5:fuka% R CMD INSTALL EcoHydrology
    * installing to library
    ?/glade/home/fuka/R/x86_64-unknown-linux-gnu-library/2.12?
    * installing *source* package ?EcoHydrology? ...
    ** libs
    ** arch -
    Makefile:123: warning: overriding commands for target `.f.o'
    /fs/local/apps/R-2.12.1/lib64/R/etc/Makeconf:132: warning: ignoring
    old commands for target `.f.o'
    gfortran -fPIC -g -O2 -c modparm.f
    gfortran -fPIC -g -O2 -c addh.f
    ---SNIP successful gfortran output----
    gfortran -fPIC -g -O2 -c zeroini.f
    gfortran -fPIC -g -O2 -c closefiles.f
    gfortran -shared -o swat.so modparm.o addh.o albedo.o
    allocate_parms.o alph.o analyse.o anfert.o apex_day.o apply.o ascrv.o
    ---SNIP successful link output----
    writeaa.o writed.o writem.o writeswatfile.o writeswatmain.o xisquare.o
    xiunc.o xmon.o ysed.o zero0.o zero1.o zero2.o zeroini.o closefiles.o
    installing to /glade/home/fuka/R/x86_64-unknown-linux-gnu-library/2.12/EcoHydrology/libs
    ** R
    ** data
    ** preparing package for lazy loading
    ** help
    *** installing help indices
    ** building package indices ...
    ** testing if installed package can be loaded

    * DONE (EcoHydrology)

    ______________________________________________
    R-devel at r-project.org mailing list
    https://stat.ethz.ch/mailman/listinfo/r-devel
  • Daniel Fuka at Mar 26, 2011 at 3:04 am
    Thanks Duncan for helping me along the way. I am working in OSX,
    Linux, and Windows, and gdb is helping me trace it along to what
    appears to be an endless processor intensive loop in sys-std.c .
    Below, I have pasted the output. All files are closed as verified by
    lsof. There is absolutely no stdio other than what I have put in a
    call to R library's subroutine intpr, all other io is routed to files,
    which are all successfully closed. The entire routine successfully
    runs, and spits out the output from intpr. Is there supposed to be
    something returned from the Fortran routine that Rstd_ReadConsole is
    looking for? I have attached the final lines of the fortran
    subroutine, as well as the gdb steps post fortran routine. Any
    additional help is greatly appreciated!

    Last few lines of fortran, where intrflag is :
    ---SNIP---
    call closefiles
    call deallocate_parms
    call intpr ("test", 4, intrflag, 1)
    return
    end

    R debug walkthrough:

    r -d gdb
    ----SNIP normal debug startup----
    library.dynam("swat","EcoHydrology")
    Reading symbols for shared libraries ... done
    .Fortran("rswat",7)
    test
    [1] 0
    [[1]]
    [1] 7

    >

    ^C
    Program received signal SIGINT, Interrupt.
    0x9172a2de in sigprocmask ()
    (gdb) next
    Single stepping until exit from function sigprocmask,
    which has no line number information.
    0x9172a23a in setjmp ()
    (gdb)
    Single stepping until exit from function setjmp,
    which has no line number information.
    0x9172a2f0 in sigaltstack ()
    (gdb)
    Single stepping until exit from function sigaltstack,
    which has no line number information.
    0x9172a25c in setjmp ()
    (gdb)
    Single stepping until exit from function setjmp,
    which has no line number information.
    0x91712fb8 in _setjmp ()
    (gdb)
    Single stepping until exit from function _setjmp,
    which has no line number information.
    R_SelectEx (n=1, readfds=0x6391a0, writefds=0x0, exceptfds=0x0,
    timeout=0x0, intr=<value temporarily unavailable, due to
    optimizations>) at ../../../../R-2.12.1/src/unix/sys-std.c:137
    137 ../../../../R-2.12.1/src/unix/sys-std.c: No such file or directory.
    in ../../../../R-2.12.1/src/unix/sys-std.c
    (gdb)
    141 in ../../../../R-2.12.1/src/unix/sys-std.c
    (gdb)
    146 in ../../../../R-2.12.1/src/unix/sys-std.c
    (gdb)
    151 in ../../../../R-2.12.1/src/unix/sys-std.c
    (gdb)
    152 in ../../../../R-2.12.1/src/unix/sys-std.c
    (gdb)
    153 in ../../../../R-2.12.1/src/unix/sys-std.c
    (gdb)
    157 in ../../../../R-2.12.1/src/unix/sys-std.c
    (gdb)
    R_checkActivityEx (usec=-1, ignore_stdin=0, intr=0x4f68a0
    <handleInterrupt>) at ../../../../R-2.12.1/src/unix/sys-std.c:330
    330 in ../../../../R-2.12.1/src/unix/sys-std.c
    (gdb)
    Rstd_ReadConsole (prompt=0x10214e0 "> ", buf=0xbfffe288
    ".Fortran(\"rswat\",7)\n", len@96, addtohistory=1) at
    ../../../../R-2.12.1/src/unix/sys-std.c:911
    911 in ../../../../R-2.12.1/src/unix/sys-std.c
    (gdb)
    912 in ../../../../R-2.12.1/src/unix/sys-std.c
    (gdb)
    904 in ../../../../R-2.12.1/src/unix/sys-std.c
    (gdb)
    911 in ../../../../R-2.12.1/src/unix/sys-std.c
    (gdb)
    912 in ../../../../R-2.12.1/src/unix/sys-std.c
    (gdb)
    904 in ../../../../R-2.12.1/src/unix/sys-std.c
    (gdb)
    911 in ../../../../R-2.12.1/src/unix/sys-std.c
    (gdb)
    912 in ../../../../R-2.12.1/src/unix/sys-std.c
    (gdb)
    904 in ../../../../R-2.12.1/src/unix/sys-std.c
    (gdb)
    911 in ../../../../R-2.12.1/src/unix/sys-std.c
    (gdb)
    912 in ../../../../R-2.12.1/src/unix/sys-std.c
    (gdb)
    904 in ../../../../R-2.12.1/src/unix/sys-std.c
    (gdb) bt
    #0 Rstd_ReadConsole (prompt=0x10214e0 "> ", buf=0xbfffe288
    ".Fortran(\"rswat\",7)\n", len@96, addtohistory=1) at
    ../../../../R-2.12.1/src/unix/sys-std.c:904
    #1 0x004394e6 in Rf_ReplIteration (rho=0x102472c, savestack=0,
    browselevel=0, state=0xbfffe27c) at
    ../../../../R-2.12.1/src/main/main.c:210
    #2 0x00439650 in R_ReplConsole (rho=0x102472c, savestack=0,
    browselevel=0) at ../../../../R-2.12.1/src/main/main.c:311
    #3 0x00439bab in run_Rmainloop () at ../../../../R-2.12.1/src/main/main.c:1004
    #4 0x00001ff0 in main ()
    (gdb)


    On Fri, Mar 25, 2011 at 8:41 AM, Duncan Murdoch
    wrote:
    On 24/03/2011 12:35 PM, Daniel Fuka wrote:

    Howdy,

    I am having a problem with a library compiled from some legacy fortran
    code. I can call the library, it runs as it should, returns a list,
    and gives a ">" prompt, but then locks up the R session. Functions
    typed in return nothing. ctrl-c results in a new prompt that is still
    locked up, and R overwhelms the processor. This happens on Mac,
    Windows, and Linux exactly the same. I close all open files and
    confirm nothing is still open with unix lsof. I also have added a
    routine to deallocate all allocated variables.

    Does anyone have any suggestions in how I might be able to debug this
    further? I have included output from the R session, top -o CPU, and R
    CMD INSTALL below.
    I would guess that the Fortran is trying to do some Fortran-style I/O; that
    often causes problems. ?See Writing R Extensions for alternatives (dblepr
    etc.). ?Or it might be some other bug.

    The best way to debug something like this is with gdb or gdb plus a front
    end like Insight, Xcode, Eclipse, etc., but if you haven't used them before,
    they are somewhat daunting. ?If you're doing this on Windows you'll need to
    rebuild your library with the environment variable DEBUG set to T to get the
    debugging information compiled into it. ?Not sure if you need to do anything
    on the other systems.

    Duncan Murdoch
    Thanks for your time on my behalf!
    dan

    Ouput from R session with library "swat" and subroutine "junk":
    ?library.dynam("swat","EcoHydrology")
    ?.Fortran("junk")
    ? ? ? ? ? ? ? ? SWAT2005
    ? ? ? Soil& ?Water Assessment Tool
    ? ? ? ? ? ? ? ?PC Version
    ?Program reading from file.cio . . . executing

    list()
    ^C
    ?q("n") ^C
    ?obejcts()

    ^C
    ?q() ^C
    ?^Z
    [1]+ ?Stopped ? ? ? ? ? ? ? ? r

    DRF28:~/cornell/ecohydrology/swat_example/SJ_R_test_mac/Scenarios/Default/TxtInOut_R
    dan$ killall R
    [1]+ ?Terminated ? ? ? ? ? ? ?r


    Output from top during lockup:
    ? PID COMMAND ? ? ?%CPU ? TIME ? #TH #PRTS #MREGS RPRVT ?RSHRD ?RSIZE
    ?VSIZE
    40750 R ? ? ? ? ? 96.6% ?1:56.07 ? 1 ? ?17 ? ? 87 ? 15M ?1384K- ? 19M
    ?49M

    Output from R CMD INSTALL:
    114 mirage5:fuka% R CMD INSTALL EcoHydrology
    * installing to library
    ?/glade/home/fuka/R/x86_64-unknown-linux-gnu-library/2.12?
    * installing *source* package ?EcoHydrology? ...
    ** libs
    ** arch -
    Makefile:123: warning: overriding commands for target `.f.o'
    /fs/local/apps/R-2.12.1/lib64/R/etc/Makeconf:132: warning: ignoring
    old commands for target `.f.o'
    gfortran -fPIC -g -O2 ? -c modparm.f
    gfortran -fPIC -g -O2 ? -c addh.f
    ---SNIP successful gfortran output----
    gfortran -fPIC -g -O2 ? -c zeroini.f
    gfortran -fPIC -g -O2 ? -c closefiles.f
    gfortran -shared ?-o swat.so modparm.o addh.o albedo.o
    allocate_parms.o alph.o analyse.o anfert.o apex_day.o apply.o ascrv.o
    ---SNIP successful link output----
    writeaa.o writed.o writem.o writeswatfile.o writeswatmain.o xisquare.o
    xiunc.o xmon.o ysed.o zero0.o zero1.o zero2.o zeroini.o closefiles.o
    installing to
    /glade/home/fuka/R/x86_64-unknown-linux-gnu-library/2.12/EcoHydrology/libs
    ** R
    ** data
    ** preparing package for lazy loading
    ** help
    *** installing help indices
    ** building package indices ...
    ** testing if installed package can be loaded

    * DONE (EcoHydrology)

    ______________________________________________
    R-devel at r-project.org mailing list
    https://stat.ethz.ch/mailman/listinfo/r-devel
  • Prof Brian Ripley at Mar 27, 2011 at 3:49 am
    You seem to have missed the force of the warning in 'Writing R
    Extensions'.

    If you include *any* Fortrann I/O in your package code, you are at
    risk from it interfering with C I/O, whether or not that Fortran I/O
    is called.

    On some platforms with gfortran, merely loading such a package's
    DSO/DLL calls the libgfortran initialization functions and they reset
    the process' stdin, causing the behaviour you saw.

    You have not told us what compilers etc you are using. On some
    versions of gfortran you can avoid this by setting the environment
    variables

    GFORTRAN_STDOUT_UNIT
    GFORTRAN_STDERR_UNIT

    to -1: these tell gfortran not to use C stdout/stderr (and because of
    what I can only see is a bug, it was the use of those which resets
    stdin).

    On Fri, 25 Mar 2011, Daniel Fuka wrote:

    Thanks Duncan for helping me along the way. I am working in OSX,
    Linux, and Windows, and gdb is helping me trace it along to what
    appears to be an endless processor intensive loop in sys-std.c .
    Below, I have pasted the output. All files are closed as verified by
    lsof. There is absolutely no stdio other than what I have put in a
    call to R library's subroutine intpr, all other io is routed to files,
    which are all successfully closed. The entire routine successfully
    runs, and spits out the output from intpr. Is there supposed to be
    something returned from the Fortran routine that Rstd_ReadConsole is
    looking for? I have attached the final lines of the fortran
    subroutine, as well as the gdb steps post fortran routine. Any
    additional help is greatly appreciated!
    ...

    --
    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
  • Daniel Fuka at Mar 27, 2011 at 7:31 pm
    Duncan and Brian,

    Thanks again for the help with this. As it turns out the suggestion of
    setting the GFORTRAN_STDIN_UNIT=-1 has the library working for Mac,
    Linux, and Windows, so it appears to be in a STDIN read somewhere. Of
    the 1100 read statements in the code, none are from stdin, or unit 5.
    Oddly enough, without the environment variable set, everything runs
    fine looping within a script called from command line (-f) which I
    delve into a bit below. So, we are functional on repo binaries, and
    standard linux distros, but intel fortran and xlf appear to have
    issues still... not a big deal, but if anyone is willing to give me
    suggestions on other things I can use to try to debug this issue, I
    would love to clear it up.

    Sorry for not giving all the background information. I am
    working/testing on Mac OSX(gfortran 4.2.3, intel fortran 11), Linux
    (gfortran 4.1.2, intel fortran 11) , WindowsXP (gfortran 4.5), and
    AIX(xlf v12.1). Right now the environment variable will work I believe
    since we are just trying to get the standard r-forge distro binaries
    to work with the package, though I shall keep looking for the STDIN
    that appears to have been opened.
    Sys.setenv(GFORTRAN_STDIN_UNIT=-1)
    library.dynam("rswat","EcoHydrology")
    .Fortran("junk",3)
    SWAT Run Successful
    [1] 0
    [[1]]
    [1] 3
    Just a bit more information here on this issue. Without the
    Sys.setenv(GFORTRAN_STDIN_UNIT=-1) function, the .Fortran call runs
    fine in a loop when called from command line script file (-f) call.
    When called from interactive session, it runs successfully, then gets
    stuck in an endless loop of lines 911, 912, 904 in in
    ../../../../R-2.12.1/src/unix/sys-std.c . There appears to be no STDIO
    in the routines, and to make sure, I am now closing all the stdio
    units at the end of the run.

    DRF28: dan$ cat test.R
    library.dynam("rswat","EcoHydrology")
    for (i in 0:5){
    .Fortran("junk",i)
    print(paste("success",i))
    }
    DRF28: dan$ r -q -f test.R
    library.dynam("rswat","EcoHydrology")
    for (i in 0:5){
    + .Fortran("junk",i)
    + print(paste("success",i))
    + }
    SWAT Run Successful
    [1] 0
    [1] "success 0"
    SWAT Run Successful
    [1] 1
    [1] "success 1"
    SWAT Run Successful
    [1] 2
    [1] "success 2"
    ----SNIP----


    On Sat, Mar 26, 2011 at 11:49 PM, Prof Brian Ripley
    wrote:
    You seem to have missed the force of the warning in 'Writing R Extensions'.

    If you include *any* Fortrann I/O in your package code, you are at risk from
    it interfering with C I/O, whether or not that Fortran I/O is called.

    On some platforms with gfortran, merely loading such a package's DSO/DLL
    calls the libgfortran initialization functions and they reset the process'
    stdin, causing the behaviour you saw.

    You have not told us what compilers etc you are using. ?On some versions of
    gfortran you can avoid this by setting the environment variables

    GFORTRAN_STDOUT_UNIT
    GFORTRAN_STDERR_UNIT

    to -1: these tell gfortran not to use C stdout/stderr (and because of what I
    can only see is a bug, it was the use of those which resets stdin).

    On Fri, 25 Mar 2011, Daniel Fuka wrote:

    Thanks Duncan for helping me along the way. I am working in OSX,
    Linux, and Windows, and gdb is helping me trace it along to what
    appears to be an endless processor intensive loop in sys-std.c .
    Below, I have pasted the output. All files are closed as verified by
    lsof. There is absolutely no stdio other than what I have put in a
    call to R library's subroutine intpr, all other io is routed to files,
    which are all successfully closed. The entire routine successfully
    runs, and spits out the output from intpr. Is there supposed to be
    something returned from the Fortran routine that Rstd_ReadConsole is
    looking for? I have attached the final lines of the fortran
    subroutine, as well as the gdb steps post fortran routine. Any
    additional help is greatly appreciated!
    ...

    --
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupr-devel @
categoriesr
postedMar 24, '11 at 4:35p
activeMar 27, '11 at 7:31p
posts5
users3
websiter-project.org
irc#r

People

Translate

site design / logo © 2022 Grokbase