Date: Thu, 23 Aug 2012 14:01:38 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: ldso: dlclose. 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. 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
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.