Alan Burlison wrote:
> > AB> from mod_perl -> perl libperl.so). Unfortunately the perl XS modules
> > AB> loaded in during startup via dlopen are *not* unloaded, nor do they
> > AB> succeed in locking the perl libperl.so into memory (you could construe
> > AB> this as a linker bug). Then Apache reloads the mod_perl libperl.so,
Actually, I retract that statement. It is *not* a linker bug. By
explicitly adding a dependency between the XS .so modules and the perl
libperl.so, the problem can be made to dissapear, as ld.so then knows
that there is a dependency between the XS module and the perl libperl.so
> > I think the linker is in error here for not adding the dependency on
> > the library and that is what should be fixed...
Nope, the *programmer* (or in this case, MakeMaker) is in error for not
specifying the dependency when the XS .so module was built.
Here's what one of our linker developers has to say about the subject:
[You may be assuming that]
> ii) the action of dlopen()'ing an object (say B.so) from an object
> (say A.so) creats a binding between the two objects that insure
> the latter cannot be deleted before the formed is deleted.
> This isn't the case. ld.so.1 maintains bindings/refence counts
> etc. between the objects it has control over - ie. a relocation
> in one object that references another. The dlopen() family are
> thought of as user code, and we do not try to interprete how
> objects are bound that use these facilities. In fact we can
> get in all sorts of issues if we do - a handle, just like a
> function pointer, can be handed to other objects, thus who
> knows what object *expects* another object to be in existance.
i.e. if you decide to use dlopen/dlclose and you screw it up, then it is
*your* fault, not the linkers. The fact that so many different systems
show the same behaviour suggests that this is a common linker design
decision.
I actually think that the real fault is in DynaLoader. If you assume
that the exiting of the perl interpreter is the same thing as the exit
of the program, then it makes sense not to dlclose anything, as it will
all be reclaimed on exit anyway. However, if you embed perl inside an
application, the exit of the perl interpreter is certainly *not* the
same thing as the program exiting, and DynaLoader should explicily
dlclose all the files it has dlopened.
I'm going to submit this as a bug to p5p.
Alan Burlison
