How to detach binary objects/libraries?

Hi all,

First, I want to apologize if this question has been already answered. I
have a RedHat 7.2. system with recently patched version of R-1.4.1. I'm
in a process of writing R package, say X, that loads some C++ code.
Currently, while adding functionality to it in both R and C++ sources,
I'm getting crashes every time I detach/load/access the C++ function(s).
Typical transcript follows:

library(X)

Loading required package: mva

is.loaded("exp_dist_fast") # The name of the C stub function

[1] TRUE

detach(package:X)
is.loaded("exp_dist_fast")

[1] TRUE # Problem?

library(X) # Load X after changes in the C/C++ code
is.loaded("exp_dist_fast") # or .C("exp_dist_fast",...)

Process R:1 segmentation fault at Mon Mar 25 12:17:57 2002

What is the way to cleanly unload the object code and is there better
mechanism than detach(package:X)?

On 25 Mar 2002, Peter Dimitrov wrote:

Hi all,

First, I want to apologize if this question has been already answered. I
have a RedHat 7.2. system with recently patched version of R-1.4.1. I'm
in a process of writing R package, say X, that loads some C++ code.
Currently, while adding functionality to it in both R and C++ sources,
I'm getting crashes every time I detach/load/access the C++ function(s).
Typical transcript follows:

library(X)

Loading required package: mva

is.loaded("exp_dist_fast") # The name of the C stub function

[1] TRUE

detach(package:X)
is.loaded("exp_dist_fast")

[1] TRUE # Problem?

library(X) # Load X after changes in the C/C++ code
is.loaded("exp_dist_fast") # or .C("exp_dist_fast",...)

Process R:1 segmentation fault at Mon Mar 25 12:17:57 2002

What is the way to cleanly unload the object code and is there better
mechanism than detach(package:X)?

Does you package use .Last.lib to unload your shared library, X.so?
If not, that will probably be your problem, as library.dynam will not
reload it (and you probably use library.dynam).

Take a look at package tcltk for an example.

library(X)

is.loaded("exp_dist_fast")

detach(package:X)
is.loaded("exp_dist_fast")

library(X)
is.loaded("exp_dist_fast")

.C("exp_dist_fast",...)

detach(package:X)

I'm not sure what Linux does if you change a shared library that is in
use, but it is not a good idea (and fatal on Solaris, for example).

-- 
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 272860 (secr)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

On Mon, 2002-03-25 at 13:46, ripley at stats.ox.ac.uk wrote:

On 25 Mar 2002, Peter Dimitrov wrote:

Hi all,

First, I want to apologize if this question has been already answered. I
have a RedHat 7.2. system with recently patched version of R-1.4.1. I'm
in a process of writing R package, say X, that loads some C++ code.
Currently, while adding functionality to it in both R and C++ sources,
I'm getting crashes every time I detach/load/access the C++ function(s).
Typical transcript follows:

library(X)

Loading required package: mva

is.loaded("exp_dist_fast") # The name of the C stub function

[1] TRUE

detach(package:X)
is.loaded("exp_dist_fast")

[1] TRUE # Problem?

library(X) # Load X after changes in the C/C++ code
is.loaded("exp_dist_fast") # or .C("exp_dist_fast",...)

Process R:1 segmentation fault at Mon Mar 25 12:17:57 2002

What is the way to cleanly unload the object code and is there better
mechanism than detach(package:X)?

Does you package use .Last.lib to unload your shared library, X.so?
If not, that will probably be your problem, as library.dynam will not
reload it (and you probably use library.dynam).

Take a look at package tcltk for an example.

Thank you, Prof. Ripley!

Adding .Last.lib solved the segmentantion fault problem. On the other
hand, it created the following puzzle. Transcript follows:

library(X)

Loading required package: mva

is.loaded("exp_dist_fast")

[1] TRUE

detach(package:X)
is.loaded("exp_dist_fast")

[1] FALSE

library(X)
is.loaded("exp_dist_fast")

[1] FALSE

.C("exp_dist_fast",...)

Error in .C("exp_dist_fast", ...),  :
	C/Fortran function name not in load table

detach(package:X)

Error in dyn.unload(x) : dynamic/shared library
"/opt/lib/R/library/X/libs/X.so" was not loaded

X's zzz.R follows:

.First.lib <- function( lib, pkg )
  library.dynam( "X", pkg, lib )

.Last.lib <- function( libpath )
  dyn.unload(
             file.path( libpath,
                       "libs",
                       paste( "X", .Platform$"dynlib.ext", sep = "" )
                       )
             )

Is the solution just to change library.dynam with dyn.load( file.path(
..))?

I'm not sure what Linux does if you change a shared library that is in
use, but it is not a good idea (and fatal on Solaris, for example).

It's probably quite wrong, but I was hoping that it will work much the
same way as in sourcing the original not-yet-in-a-package R file that
dynamically loads X.so. In Linux it reloads X.so without a problem.

But my point was: what does changing the file copy of an already loaded
shared library do?   It's not allowed on Windows, and on Solaris it will
lead to a crash.  I don't know about Linux, as I would never try it
given my experience.

Prof Brian D Ripley <ripley at stats.ox.ac.uk> writes:

But my point was: what does changing the file copy of an already loaded
shared library do?   It's not allowed on Windows, and on Solaris it will
lead to a crash.  I don't know about Linux, as I would never try it
given my experience.

AFAIR, it works on Linux. Running processes just continue using the
old version (which gets unlinked in the usual Unix way and goes away
when no more processes are using it). E.g., you can upgrade the
readline library without crashing all running instances of bash...