[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 24 Aug 2012 08:27:08 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: ldso: dlclose.
On Fri, Aug 24, 2012 at 09:52:28AM +0200, musl wrote:
> On 23/08/2012 20:01, Rich Felker wrote:
> > On Fri, Aug 24, 2012 at 12:02:09AM +0800, orc wrote:
> >> On Thu, 23 Aug 2012 08:48:16 -0400
> >> Rich Felker <dalias@...ifal.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.
> Indeed, many plugins implem rely on constructors/destructors to
> allocate/free memory or intialize/cleanup context.
> This may lead to memory leaks or other issues if the plugin is
> loaded/unloaded multiple times.
A plugin cannot be loaded more than once. Subsequent calls to dlopen
use the existing loaded image. The only way it could be loaded again
is if the file were replaced by a new version.
I think maybe you're not realizing that the "leak" can only happen if
a new version of the .so file is put in place of the old one...
> > 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...
> It might be worst for long-lived apps running in a memory
> constrained environment (embedded systems).
Yes, but in this kind of system, ANY use of dynamic memory allocation
is frowned upon. Dynamic module loading even moreso. And of course I
don't think you'll be constantly replacing .so files on such a system
with new versions.
> > 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).
> Does this mean you want to call plugin destructors in dlclose
> function and keep the plugin memory mapping ?
No. Calling dtors and unloading always come in a pair. You cannot call
dtors but keep and reuse the mapping because the static-storage
objects would retain their old values from the prior load, but a new
load would be visible to the code in the plugin.
The potential design I'm talking about would have only the dlopen'd
library itself ever unloaded/unmapped. For example, if myplugin.so
depends on libfoo.so and libbar.so, libfoo.so and libbar.so, which
were implicitly loaded when loading myplugin.sh, will never be
unmappable. Only myplugin.so itself would be unmappable. On
unloading/unmapping dtors would be called as usual, and then the
reference would be removed entirely from the DSO chain, causing it to
be searched-out and loaded new next time dlopen is called.
I do not want to do this except as a last resort, since as I've
already mentioned it's highly error-prone (see glibc) and fragile.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
