[Rd] unloading compiled code.

Andrew Redd amredd at gmail.com
Thu Nov 18 17:12:08 CET 2010


I thought I would update with what I did.  Not liking overwriting the
.Last function in case another package I decided to see if the
reg.finalizer would work.  This is what my .onLoad function look like.
---
.onLoad<-function(libname, pkgname){
	e<-emptyenv()
	library.dynam('gpuBayes',package=pkgname)
	reg.finalizer(e,function(...){unloadNamespace(pkgname)},T)
}
.onUnload<-function(libpath){
	library.dynam.unload('gpuBayes',libpath)
}
---
 This takes attaches a reg.finalizer to the empty environment with
onexit=T.  Since the empty environment will never be collected this
will only run on exit.

-Andrew

On Tue, Nov 16, 2010 at 6:34 PM, Charles C. Berry <cberry at tajo.ucsd.edu> wrote:
> On Tue, 16 Nov 2010, Andrew Redd wrote:
>
>> so should I use reg.finalizer or overwrite .Last()?
>
>> .Last
>
> Error: object '.Last' not found
>>
>
> You create your own .Last - there is nothing to overwrite.
>
> Chuck
>
>
>  If I use
>>
>> reg.finalizer, what should be the environment that I specify?  The
>> straight forward solution would be to have a hook .onExit that a
>> package could specify to make sure  that the code was unloaded before
>> the program terminates, that way I don't overwrite .Last if if has
>> another purpose.
>>
>> -Andrew
>>
>> On Tue, Nov 16, 2010 at 11:27 AM, Charles C. Berry <cberry at tajo.ucsd.edu>
>> wrote:
>>>
>>> On Tue, 16 Nov 2010, Andrew Redd wrote:
>>>
>>>> Just found in the documentation for getHook that packages are not
>>>> unloaded on quit.  How should I force a package to unload on quit?
>>>
>>> See
>>>
>>>        ?q
>>>
>>>
>>> HTH,
>>>
>>> Chuck
>>>
>>>>
>>>> -Andrew
>>>>
>>>> On Tue, Nov 16, 2010 at 10:25 AM, Andrew Redd <amredd at gmail.com> wrote:
>>>>>
>>>>> Are packages unloaded on quit so that the .Last.lib or .onUnload are
>>>>> called for packages?
>>>>>
>>>>> -Andrew
>>>>>
>>>>> On Fri, Nov 12, 2010 at 3:52 PM, Andrew Redd <amredd at gmail.com> wrote:
>>>>>>
>>>>>> Perhaps you could help me make some sense of this.  Here is a printout
>>>>>> of my sessions.
>>>>>> ---
>>>>>> toys$R -q
>>>>>>>
>>>>>>> library(test2)
>>>>>>> gpualloctest()
>>>>>>
>>>>>> testing allocation on gpu
>>>>>> C Finished
>>>>>> Collecting Garbage
>>>>>> done.
>>>>>>>
>>>>>>> q()
>>>>>>
>>>>>> Save workspace image? [y/n/c]: n
>>>>>>
>>>>>>  *** caught segfault ***
>>>>>> address 0x7f12ec1add50, cause 'memory not mapped'
>>>>>>
>>>>>> Possible actions:
>>>>>> 1: abort (with core dump, if enabled)
>>>>>> 2: normal R exit
>>>>>> 3: exit R without saving workspace
>>>>>> 4: exit R saving workspace
>>>>>> Selection: 1
>>>>>> aborting ...
>>>>>> Segmentation fault
>>>>>> toys$R -q
>>>>>>>
>>>>>>> library(test2)
>>>>>>> gpualloctest()
>>>>>>
>>>>>> testing allocation on gpu
>>>>>> C Finished
>>>>>> Collecting Garbage
>>>>>> done.
>>>>>>>
>>>>>>> library.dynam.unload('test2',system.file(package='test2'))
>>>>>>> q()
>>>>>>
>>>>>> Save workspace image? [y/n/c]: n
>>>>>> toys$
>>>>>> ---
>>>>>>
>>>>>> I have a in the test2/R/zzz.R file
>>>>>> ---
>>>>>> .onUnload <- function(libpath)
>>>>>>    library.dynam.unload("test2", libpath)
>>>>>> ---
>>>>>>
>>>>>> so the code should be unloaded.  But it appears that it is not from
>>>>>> errors when I explicitly unload the test2.so it does not through a
>>>>>> segfault.  Why would this be happening?  and how do I circumvent it.
>>>>>>
>>>>>> thanks,
>>>>>> Andrew
>>>>>>
>>>>>>
>>>>>> On Fri, Nov 12, 2010 at 3:32 PM, Prof Brian Ripley
>>>>>> <ripley at stats.ox.ac.uk> wrote:
>>>>>>>
>>>>>>> On Fri, 12 Nov 2010, Andrew Redd wrote:
>>>>>>>
>>>>>>>> I have a package that I'm developing that I need to unload the
>>>>>>>> library.  Long story short I figured out that the leaving the
>>>>>>>> compiled
>>>>>>>> code loaded lead to a segmentation fault, but unloading the code
>>>>>>>> will
>>>>>>>> fix it.  I've read the documentation and it appears that there are
>>>>>>>> several ways to do this?  What is the popper accepted current
>>>>>>>> standard
>>>>>>>> for unloading compiled code?
>>>>>>>
>>>>>>> Depends how you loaded it: you basically reverse the process.
>>>>>>>
>>>>>>>> The options as I understand them are:
>>>>>>>> 1. dyn.unload
>>>>>>>> 2. library.dynam.unload
>>>>>>>> used with either
>>>>>>>> A. .Last.lib
>>>>>>>> B. .onUnload
>>>>>>>>
>>>>>>>> If it makes a difference my package does use a NAMESPACE so the
>>>>>>>> package is loaded through useDynLib.
>>>>>>>
>>>>>>> So you need an .onUnload action calling library.dynam.unload.
>>>>>>>
>>>>>>> Slightly longer version: you need the DLL loaded whilst the namepace
>>>>>>> is
>>>>>>> in
>>>>>>> use, so it has to be in .onUnload, and useDynLib calls library.dynam
>>>>>>> so
>>>>>>> you
>>>>>>> need library.dynam.unload to do the housekeeping around dyn.unload
>>>>>>> which
>>>>>>> matches what library.dynam does around dyn.load.
>>>>>>>
>>>>>>> There are quite a lot of examples to look at, including in R itself.
>>>>>>> MASS is
>>>>>>> one example I've just checked.
>>>>>>>
>>>>>>> Having said all that, my experience is that unloading the DLL often
>>>>>>> does not
>>>>>>> help if you need to load it again (and that is why e.g. tcltk does
>>>>>>> not
>>>>>>> unload its DLL).
>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Andrew Redd
>>>>>>>>
>>>>>>>> ______________________________________________
>>>>>>>> R-devel at r-project.org mailing list
>>>>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ______________________________________________
>>>> R-devel at r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>
>>>
>>> Charles C. Berry                            Dept of Family/Preventive
>>> Medicine
>>> cberry at tajo.ucsd.edu                        UC San Diego
>>> http://famprevmed.ucsd.edu/faculty/cberry/  La Jolla, San Diego
>>> 92093-0901
>>>
>>>
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> Charles C. Berry                            Dept of Family/Preventive
> Medicine
> cberry at tajo.ucsd.edu                        UC San Diego
> http://famprevmed.ucsd.edu/faculty/cberry/  La Jolla, San Diego 92093-0901
>
>



More information about the R-devel mailing list