From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9353 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: dynlink.c: bug in reclaim_gaps leading to segfault in __libc_exit_fini Date: Thu, 18 Feb 2016 13:33:34 -0500 Message-ID: <20160218183333.GE9349@brightrain.aerifal.cx> References: <20160216215550.GC9915@port70.net> <20160217090327.4c6b5790@vostro.util.wtbts.net> <20160217101916.GD9915@port70.net> <20160218180513.GA3969@port70.net> 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 1455820432 22923 80.91.229.3 (18 Feb 2016 18:33:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 18 Feb 2016 18:33:52 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9366-gllmg-musl=m.gmane.org@lists.openwall.com Thu Feb 18 19:33:51 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aWTOh-0002Xt-9K for gllmg-musl@m.gmane.org; Thu, 18 Feb 2016 19:33:51 +0100 Original-Received: (qmail 18152 invoked by uid 550); 18 Feb 2016 18:33:48 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 18134 invoked from network); 18 Feb 2016 18:33:47 -0000 Content-Disposition: inline In-Reply-To: <20160218180513.GA3969@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9353 Archived-At: On Thu, Feb 18, 2016 at 07:05:13PM +0100, Szabolcs Nagy wrote: > * Szabolcs Nagy [2016-02-17 11:19:17 +0100]: > > * Timo Teras [2016-02-17 09:03:27 +0200]: > > > Well - musl really should introduce __donatemem or similar for this > > > purpose, and not overload the standard free() function. This would make > > > the valgrind warning go away. > > > > to please valgrind the options are > > > > 1) have an internal free which valgrind does not know > > about, but public free calls it, so all public calls > > of free would go through an extra indirection. > > > > 2) have a copy of the internal logic of free under a > > different name, which means maintenance work and > > code size increase. > > > > 3) or have a suppression file. > > > > i think 3) is a reasonable solution. > > i looked at this again: i think moving most of reclaim() > function into src/malloc makes sense, so all malloc > internal knowledge is at one place (even if dynlink.c > is the only user of this code). > > but i don't see an easy way to do the reclaim without > calling free (so the valgrind problem is not solved, > only code maintenance gets better) I think it could be done by making free a wrapper with zero cost. See how free starts out with: if (!p) return; This could instead be: if (p) return do_free(p); /* end of function */ and the return statement is just a conditional tail-call jump, same cost as the conditional branch in the current code. This would also fix malloc-internal calls to free (which might confuse valgrind?) and eliminate the useless branch to test for null pointer when free is called internally from malloc/realloc. Rich