Re: [Rd] unloading compiled code.

From: Andrew Redd <amredd_at_gmail.com>
Date: Tue, 16 Nov 2010 10:25:27 -0700

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 Received on Tue 16 Nov 2010 - 17:32:09 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Tue 16 Nov 2010 - 18:40:22 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.

list of date sections of archive