double dyn.load hang up

I had a rather mysterious problem that now seems to have been
attributable to dyn.load()ing the same object twice in one R session
and I would be curious to know if this is a known issue, or something
that I should try to document further:

I had a single fortran subroutine which I was making into a .so file
with the usual R CMD SHLIB ritual.  Then I would run a test problem
which involved dyn.load()ing the .so object, sourcing an R function
that called .Fortran, generating some random data and finally invoking
the R function when I sourced a file that looked like this:

# Initial test of parq algorithm
p <- 30
n <- 200
x <- matrix(rnorm(p*n),n,p)
y <- rnorm(n)
dyn.load("parq.so")
source("parq.q")
z <- parq(x,y,lambda = -1)

That is z contained a perfectly sensible result, but when I sourced  
this
file a second time and then tried to look at "z"  the R process  
hung.  This
happened on both my old G5 desktop running 2.7.1 and on a new intel
mac-pancake running 2.7.1.  However, on several other machines 3
linuxes and one solaris everything was copasetic, no hangups after
the second invocation.

After much agonizing under the assumption that there was something
wrong with memory allocation in my fortran -- a hypothesis that had
quite a lot of historical support -- I finally tried just running  
the parq
function without the double  invocation of dyn.load  and this worked
perfectly.  From which I draw the moral:

	Don't dyn.load twice, it's not (mac)-nice.

url:    www.econ.uiuc.edu/~roger            Roger Koenker
email    rkoenker at uiuc.edu            Department of Economics
vox:     217-333-4558                University of Illinois
fax:       217-244-6678                Champaign, IL 61820

Roger,

can you give us a simple, reproducible example, please? From your  
description it's not clear to me what is your speculation and what  
are the facts. Running dyn.load twice is very dangerous in general  
unless you know what you're doing, especially with dylibs involving  
Fortran, because those usually contain initializer functions that  
may have unexpected side effects. This is common to all platforms,  
not just Macs.

Cheers,
Simon


On Aug 25, 2008, at 18:23 , roger koenker wrote:

I had a rather mysterious problem that now seems to have been
attributable to dyn.load()ing the same object twice in one R session
and I would be curious to know if this is a known issue, or something
that I should try to document further:

I had a single fortran subroutine which I was making into a .so file
with the usual R CMD SHLIB ritual.  Then I would run a test problem
which involved dyn.load()ing the .so object, sourcing an R function
that called .Fortran, generating some random data and finally  
invoking
the R function when I sourced a file that looked like this:

# Initial test of parq algorithm
p <- 30
n <- 200
x <- matrix(rnorm(p*n),n,p)
y <- rnorm(n)
dyn.load("parq.so")
source("parq.q")
z <- parq(x,y,lambda = -1)

That is z contained a perfectly sensible result, but when I sourced  
this
file a second time and then tried to look at "z"  the R process  
hung.  This
happened on both my old G5 desktop running 2.7.1 and on a new intel
mac-pancake running 2.7.1.  However, on several other machines 3
linuxes and one solaris everything was copasetic, no hangups after
the second invocation.

After much agonizing under the assumption that there was something
wrong with memory allocation in my fortran -- a hypothesis that had
quite a lot of historical support -- I finally tried just running  
the parq
function without the double  invocation of dyn.load  and this worked
perfectly.  From which I draw the moral:

	Don't dyn.load twice, it's not (mac)-nice.

url:    www.econ.uiuc.edu/~roger            Roger Koenker
email    rkoenker at uiuc.edu            Department of Economics
vox:     217-333-4558                University of Illinois
fax:       217-244-6678                Champaign, IL 61820