[ESS] ESS + R+ gfortran on windows crash on dyn.unload()

Kasper Daniel Hansen khansen at stat.Berkeley.EDU
Sun Dec 2 22:55:38 CET 2007


I do not know too much about Fortran, but my guess is that you are  
doing unsupported stuff by printing and this crashes under ESS which  
uses another console than cmdline windows.

For example, it is not supported to use
   printf
in C programs. You should instead use
  Rprintf
from the R API. Using printf may or may not crash R and should really  
not be done. I would guess there is a similar function for Fortran  
and I would also guess that this is explained in R-exts.

Kasper

On Nov 30, 2007, at 11:05 AM, Richard Arnold wrote:

> I am running R-2.6.1 under Windows XP SP2 (2002) [Toshiba,  Intel
> Celeron 1.4Ghz, 704Mb RAM] with MSYS+MinGW(Rtools)
> using emacs (22.1) with ESS (version 5.3.5) which I invoke with
> inferior-R-args = "--no-save"
>
> I have the following Fortran routine in a file ff77.f
>
>       SUBROUTINE G(X,FVAL)
>       REAL*8 X, FVAL
>       FVAL = X**2
>       WRITE(6,*) 'X,G(X)=',X,FVAL
>       CALL FLUSH
>       END
>
> and the following R code in a file test.q
>
> g <- function(x) .Fortran("g",as.double(x),as.double(0))[[2]]
> system("R CMD SHLIB ff77.f")
> dyn.load("ff77.dll")
> print(is.loaded("g"))
> print(g(4))
> dyn.unload("ff77.dll")
> print(is.loaded("g"))
> print(sqrt(2))  # just to have something to print
> cat("Finished\n")
>
> If I run the R code directly from the operating system command line  
> (in
> MSYS) with
>
> R --no-save < test.q
>
> I get the output:
>
>> g <- function(x) .Fortran("g",as.double(x),as.double(0))[[2]]
>> gfortran-sjlj   -O3  -c ff77.f -o ff77.o
> gcc-sjlj  -std=gnu99  -shared -s  -o ff77.dll ff77.def ff77.o
> ff77_res.o  -Lc:/PROGRA~1/R/R-26~1.1/bin   -lgfortran -lR
> system("R CMD SHLIB ff77.f")
>> dyn.load("ff77.dll")
>> print(is.loaded("g"))
> [1] TRUE
>> print(g(4))
>  X,G(X)=   4.00000000000000        16.0000000000000
> [1] 16
>> dyn.unload("ff77.dll")
>> print(is.loaded("g"))
> [1] FALSE
>> print(sqrt(2))
> [1] 1.414214
>> cat("Finished\n")
> Finished
>>
>
> This is fine - everything works as it should
> I now type open R in emacs, make a trivial edit to f77.f to force  
> it be
> recompiled,  and put each line of test.q into R one by one using
> eval-line-and-step and this happens
>
>> g <- function(x) .Fortran("g",as.double(x),as.double(0))[[2]]
>> system("R CMD SHLIB ff77.f")
> gfortran-sjlj   -O3  -c ff77.f -o ff77.o
> gcc-sjlj  -std=gnu99  -shared -s  -o ff77.dll ff77.def ff77.o
> ff77_res.o  -Lc:/PROGRA~1/R/R-26~1.1/bin   -lgfortran -lR
>> dyn.load("ff77.dll")
>> print(is.loaded("g"))
> [1] TRUE
>> print(g(4))
>  X,G(X)=   4.00000000000000        16.0000000000000
> [1] 16
>> dyn.unload("ff77.dll")
>>
>
> Process R finished at Fri Nov 30 10:44:26 2007
>
> i.e. the fortran code works but R crashes at dyn.unload() - (and if I
> don't use inferior-R-args= --no-save then I get asked repeatedly and
> indefinitely about saving the workspace image - and have to terminate
> Rterm using the Task Manager)
>
> If instead I open R in emacs and go
>      source("test.q")
> then this happens:
>
>> source("test.q")
> gfortran-sjlj   -O3  -c ff77.f -o ff77.o
> gcc-sjlj  -std=gnu99  -shared -s  -o ff77.dll ff77.def ff77.o
> ff77_res.o  -Lc:/PROGRA~1/R/R-26~1.1/bin   -lgfortran -lR
> [1] TRUE
>  X,G(X)=   4.00000000000000        16.0000000000000
> [1] 16
> [1] FALSE
> [1] 1.414214
> Finished
>>
>
> Process R finished at Fri Nov 30 10:47:45 2007
>
> i.e. the code runs but R still exits without being asked to do so.
>
> The problem seems be caused by the WRITE(6,*) statement.  If I comment
> it out then all three approaches work with no trouble.
>
> In summary:
> + the fortran code compiles OK, and always runs when R is invoked from
> the operating system
> + it runs but R exits unexpectedly when dyn.unload() is called when
> running R from inside emacs
> Also note:
> + calls to WRITE(6,*) of this form worked fine with emacs+ESS under  
> g77
> (as opposed to gfortran used here) [and the CALL FLUSH command wasn't
> needed to flush the buffer and prevent the WRITE output being deferred
> until R exits]
> + I get identical behaviour whenever I try to use the
> ALLOCATE/DEALLOCATE commands in .f95 code: works under the operating
> system, but not under emacs/ESS - so it's not just a problem with  
> WRITE()
>
> I can live without WRITE() [calls to C routines using printf() have no
> trouble - I've tried this], but really want to be able to use ALLOCATE
> in .f95 - but both WRITE and ALLOCATE seem to cause the same problem.
>
> My question is: what is ESS doing differently form the operating  
> system
> - and is there some way to stop it?
>
> Any help appreciated!
> Thanks
> Richard
>
> ______________________________________________
> ESS-help at stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/ess-help




More information about the ESS-help mailing list