[R-SIG-Mac] double dyn.load hang up

[roger koenker]

Simon,

Running dyn.load twice is certainly dumb, I just didn't realize that  
it was also
dangerous.  (And I was surprised, in retrospect, that it didn't also  
cause
problems on our linux boxes.)  I've put a toy example at:

	http://www.econ.uiuc.edu/~roger/research/qss/toy.tar.gz

that I hope will be self explanatory.   Thanks for looking into this,  
of course
I recognize that this probably fits into the category of trimming my  
toenails
with a chainsaw that shouldn't be covered by product liability -- even  
if there
were product liability for R, which there isn't.

Roger

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


On Aug 26, 2008, at 8:32 AM, Simon Urbanek wrote:

> 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
>>
>> _______________________________________________
>> R-SIG-Mac mailing list
>> R-SIG-Mac at stat.math.ethz.ch
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>
>>