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 <amr...@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
> <rip...@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@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>> --
>> Brian D. Ripley, rip...@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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
