From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1703 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: ldso: dlclose. Date: Thu, 23 Aug 2012 14:01:38 -0400 Message-ID: <20120823180138.GR27715@brightrain.aerifal.cx> References: <503113C5.5010206@gmail.com> <20120820004803.GA27715@brightrain.aerifal.cx> <5603ddad712718518eed1430f5d00450@exys.org> <20120823124816.GP27715@brightrain.aerifal.cx> <20120824000209.74ab2a3b@sibserver.ru> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1345744810 8438 80.91.229.3 (23 Aug 2012 18:00:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Aug 2012 18:00:10 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1704-gllmg-musl=m.gmane.org@lists.openwall.com Thu Aug 23 20:00:09 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 1T4bhO-0004Z1-0L for gllmg-musl@plane.gmane.org; Thu, 23 Aug 2012 20:00:06 +0200 Original-Received: (qmail 30610 invoked by uid 550); 23 Aug 2012 18:00:04 -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 30602 invoked from network); 23 Aug 2012 18:00:03 -0000 Content-Disposition: inline In-Reply-To: <20120824000209.74ab2a3b@sibserver.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1703 Archived-At: 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. 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