MEX shared libraries aren't unloaded

[Aravindh Krishnamoorthy]

Dear,

Octave version info: GNU Octave, version 3.0.3
Computer info: Octave was configured for "i686-pc-linux-gnu".

Problem:
1. MEX files (sharedlib) are not unloaded until Octave's exit.
2. 'clear function <mex-function>' does not unload the library.
3. OS's such as Windows do not allow writing to the MEX file while
it's loaded => recompilation is not possible until Octave is exit.

Addnl info:
1. Similar problem is not seen with OCT (DLD) files. 'clear function
<dld-function>' unloads the associated shared library.

Analysis:
The problem is due to two reasons:
1. src/dynamic-ld.cc: octave_dynamic_loader::do_remove => Attempts
removal of all (DLD, MEX) from the 'octave_shlib_list' while MEX files
list is maintained in 'octave_mex_file_list.'
2. src/dynamic-ld.cc: octave_dynamic_loader::do_load_mex => Attempts
to search for 'mexFunction', '_mexFunction' and F77's mexFunction
using 'octave_shlib->search' function which automatically adds symbol
name ('mexFunction', etc) instead of 'fcn_name' to the function name
list. Hence, during removal of library, using
'octave_dynamic_loader::do_remove -> octave_shlib::remove', 'fcn_name'
and symbol name never match.

Solution:
1. To solve 1) above, we separate the remove function into
'octave_dynamic_loader::remove_mex' and
'octave_dynamic_loader::remove_oct' which are called respectively from
ov-mex-fcn.cc: octave_mex_function::~octave_mex_function, and
ov-dld-fcn.cc: octave_dld_function::~octave_dld_function; and use the
proper lists in the do_remove_XXX. This separation is in line with the
separation in load => load_mex, load_oct.
2) To solve 2) above, we use the 'mangler function' to return
'mexFunction', etc to octave_shlib::search routine, which in this
case, searches for the output of 'mangler function' while adding
'fcn_name' to the function name list (liboctave/oct-shlib.cc:
protected string_vector octave_base_shlib::fcn_names.)

Look out:
As the binding between 'fcn_name' and MEX function is not maintained
by us, so we do not maintain reference count (per MEX file) either.
This means that if there's a file called mex.mex, and it's also loaded
as 'autoload('brrr', file_in_loadpath('mex.mex'))' both the functions
'mex' and 'brrr' refer to the same MEX file. The way things are
organised, mex.mex is loaded twice => Reference counting is offloaded
to libdl (or whatever.)
This is fair as dlopen/close, shl_load/unload, Load/FreeLibrary
maintain a reference count and unmap the library only when sufficient
close calls are made. Hence, in our case if 'clear function brrr' is
executed, mex.mex is not unmapped as one dlopen is not matched.

=> What about 'mach-o/dynld.h' functions? Anybody knows whether they
reference-count the shlib usage?

Patch:
begin-base64 644 patch.gz
H4sICHMfWkkCA3BhdGNoANVYW2/iVhB+Jr9i2EopDpiYOzFK9yHaVJF2U6nd
ttsn62Afx9YaG9kHulGV/e2dc/ENDBhII9VCwpzLzDf3GRzfdUG3l6A7ENmM
rKk+6BrdwXUS29fOc0gWvq0HTte2S9s6ib9uH7m4uro6QKXRN4ypbtzo/SH0
+uZwYA5vukb6QNsYDYwLXddrcJOken19YEBvag5G5nCyReqq/CiyliJkBRFx
aGyaTiRerQX9Bi07ChMhynA46AzHBvCbFwANwOef9AVSWnjHcv2AWoGfMNMk
yyUNHWily9oMb1w000vuKrSZH4VwC+mJbkJJbHvQeocr92r/nbyXMfNdaDWz
2xrfaAgsuH99DfcPXz59ANSbTUL4m4JDGY0XfkiBeX4Cd7Ag4VPgh0+Q2B5d
0PwmWbFoQZhvkyB4BsIgXoXA/AWFKAZUhes/rWIqVt4rSRoHxLAq5WhUCyGV
2lRv+yn/9vnXh8efH+7/gtb9ZGLd//54JxSd3unApw9f+Ornh18eNU2wbhQU
WObc8Lj5XG7zW2DxiubHX4QPpvbHd/0t7O/aoYV+STtiK0SjIHkasvj5/+sM
ZZlWIYZbYkfxplyv4BxlTm4Us5iEBTYnOsJ5GWTa6wynkzSDvEhp51EUoFC7
KcV0Ea2ppMMgYY5pJixGg11CLqW6nniBP78E/OLCcC+QDCCmbE0ClMglQSJE
kk6tICmnPg6ShQdeH1Z9FZcVI1Q8MozOyBhJFXMBxQKWlwoB24cFzOx3jIBt
FLC9S8A2iD2Mrj8xFKPwRwYhpQ6wCH8BCZ8xKDEU0S1FdOKHRx8emFObrBLK
I5hg0PlhSod5FJZxZNMkgchFhlwMToNAl+PnYYGHMHw9gtQ8jHbqdFMgMs6c
CC8I+TWxCkoE/mQSoHDdVOWpArRMojSY+KlwtZjT2IpcKw2tRCoXM6EGt7dg
cDaN6pSZsuC6nCnSLykXBLOKQ4WJ76odYVDYZVARiwedVUZ/A6rOcHilQ8q4
gUjLWl2nLScFZCKdtjdFHx0flRfOSQrNXJEtH6+T0MZY/oq20eA9pCv6T4UQ
y2lyKmDm8arQFhDIuBtMOqNR76jEcm5WOVouyWqXbE1E3eRVrRbqk1JF8yTU
gtVRFqnpnqITkI5eKFvClMN+IaeO+53RdJTadisqFYR2CcLObLvZ3VRoES7z
rKp4FXY3OmUopIXaADZbkaNBbDW6J8Eo9SknYDi2Jc5BYinhuWc2m8HHCEsO
/EFin8wDmpgg0xLfWkQONeGu3RZrTs1x0Ts4v3kHh0Xv1WZFrzQqGiZ+jMHB
UXG5mge+bco+DuNhkM2Bjca+gsHrZtFCmqogpfqRtgfpdMCDl/fdaZU5KdWr
ZnoZ+2vCqJl1fDwvZ0PMG4E/KafPZPatpHdKtq1QyJaV0z3+Y3zTmfZyM/NE
d4KyCq3uLn2J7dMbfSVXWU95R5eJHTFqM+qYG8eLoLcKwAYM1fJhgldUf8Dp
1neFY016nek0d6y3Utd5rrVB6wy3ekP1t3fcrlVIYe/9enVwP40aRQwqfGhv
NYnWuhM4Otph55+PpSPV9aR05LyCUkFKVZSh2b8x++Pafz4GTjYlmWbFouzB
Jp1xVnIKg07p8veKVWitI9/J++MD48TiOWsqcRyba/s6fAFJxft/BkmGd01Y
h1wIvfOQC+VHdrpQfuRsF9okVXQho7YLiaDbUnlhVZYzozPOZkw5q9NvPrN4
bluyWLuQM3zrqrSKiTlLvK/nOxJLNj+8NhaZx2vi+RcovIrT9RgAAA==
====

-- ARK