From amredd at gmail.com  Fri Nov 12 23:52:22 2010
From: amredd at gmail.com (Andrew Redd)
Date: Fri, 12 Nov 2010 15:52:22 -0700
Subject: [Rd] unloading compiled code.
In-Reply-To: <alpine.LFD.2.00.1011122223410.32247@gannet.stats.ox.ac.uk>
References: <AANLkTimR+c8r=gBPKb9-EFcUr-wCVeS6+EJSNXBH3zHz@mail.gmail.com>
	<alpine.LFD.2.00.1011122223410.32247@gannet.stats.ox.ac.uk>
Message-ID: <AANLkTinDzRiHugMKOu+rje4PAXWReEJpQY8=6ZfUAJyL@mail.gmail.com>

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
>



[Rd] unloading compiled code.
Andrew Redd