[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <503732BC.1030507@gmail.com>
Date: Fri, 24 Aug 2012 09:52:28 +0200
From: musl <b.brezillon.musl@...il.com>
To: musl@...ts.openwall.com
Subject: Re: ldso: dlclose.
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.
>
> 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).
>
> 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 ?
>
> 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.
