Re: ldso: dlclose.

[Rich Felker <dalias@aerifal.cx>]

On Fri, Aug 24, 2012 at 12:02:09AM +0800, orc wrote:
> On Thu, 23 Aug 2012 08:48:16 -0400
> Rich Felker <dalias@aerifal.cx> wrote:
> 
> > Anyway, unless the issue is fixed in binutils so that the vast
> > majority of libraries are marked non-unloadable, I don't see anything
> > we can do in musl. "glibc does it that way too" is not an excuse for
> > adding unsafe/non-robust behavior to musl.
> > 
> > Rich
> 
> The whole dlopen/dlclose/dlsym functions family are 'harmful': even if
> we want static linking, application will still rely on them and fail
> invisibly, creating more headaches.
> I think better leave dlclose() in it's current state now. It will always
> 'success', nobody will care.

In my view, there are only two downsides to the current behavior:

1. Some buggy plugin-based applications may expect dlclose(plugin) to
call the destructors in the plugin. This is of course an invalid
expectation per POSIX, but it may be the reality for some apps.

2. In an extremely long-lived app that loads and unloads plugins which
may be upgraded multiple times during the application's lifetime, each
new version of the plugin will consume additional virtual memory space
and commit charge, i.e. you have a memory leak. In the real world the
leak should be very slow, but it could become significant if the
plugins are very large and get reinstalled many times, perhaps if
someone is experimenting and running "make install" each time...

In my view #2 is a very low-priority problem that's not worth caring
about on its own, but #1 may be relevant. If does become an important
issue that we can't get fixed at the application level, I think the
solution would be to add unloading, but have it only take effect for
the actual argument to dlopen/dlclose, never any libraries implicitly
loaded as dependencies (and of course to honor the flag that prevents
unloading).

Rich