[Rd] .Fortran successful, R locks up.

[Prof Brian Ripley]

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