From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1713 Path: news.gmane.org!not-for-mail From: musl Newsgroups: gmane.linux.lib.musl.general Subject: Re: ldso: dlclose. Date: Fri, 24 Aug 2012 09:52:28 +0200 Message-ID: <503732BC.1030507@gmail.com> References: <503113C5.5010206@gmail.com> <20120820004803.GA27715@brightrain.aerifal.cx> <5603ddad712718518eed1430f5d00450@exys.org> <20120823124816.GP27715@brightrain.aerifal.cx> <20120824000209.74ab2a3b@sibserver.ru> <20120823180138.GR27715@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1345794763 4751 80.91.229.3 (24 Aug 2012 07:52:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 Aug 2012 07:52:43 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1714-gllmg-musl=m.gmane.org@lists.openwall.com Fri Aug 24 09:52:44 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1T4oh9-0007j1-RI for gllmg-musl@plane.gmane.org; Fri, 24 Aug 2012 09:52:43 +0200 Original-Received: (qmail 3425 invoked by uid 550); 24 Aug 2012 07:52:41 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 3417 invoked from network); 24 Aug 2012 07:52:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=G87Y7dl03PFsqi9W2ckpg5H4PdWnp3rrsYNm/Fa58Bg=; b=RFGniShwC6NoTDzmD0+fYi7KblorPlfvoS0qhkjZ/5VXRERKCqqq7Crlb/N0A+VNU7 geClBpolAQOElRES3N3cugslU65kjDfxNx8323lJxt8ghdnovAX5BgLWTtUNtHTOIR1I A+wngiDY10hrbNdGCqC4EtbfhJy3Gvk4jMYooHZYGpqz+hCC7NgJOL4ZRUvA+pmexblI yzkHK8W2Zg4+gzdlAq2gewOml5brgUgC68j6k7rGUhrMNwfIv0NLK/Fp5UXCdGAuCUeP O4exLYCx1VLrbdY5ifoJ+zXsm108pC7hzng4QRrET6faH4ym+KOYJOSwxK8oF42DV6Yn rLyQ== User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 In-Reply-To: <20120823180138.GR27715@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:1713 Archived-At: 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 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