From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14969 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: New malloc - first preview Date: Sat, 30 Nov 2019 17:11:50 -0500 Message-ID: <20191130221150.GT16318@brightrain.aerifal.cx> References: <20191022174051.GA24726@brightrain.aerifal.cx> <20191128215642.GN16318@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="86755"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14985-gllmg-musl=m.gmane.org@lists.openwall.com Sat Nov 30 23:12:08 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1ibAyF-000MTK-25 for gllmg-musl@m.gmane.org; Sat, 30 Nov 2019 23:12:07 +0100 Original-Received: (qmail 20042 invoked by uid 550); 30 Nov 2019 22:12:03 -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 20016 invoked from network); 30 Nov 2019 22:12:03 -0000 Content-Disposition: inline In-Reply-To: <20191128215642.GN16318@brightrain.aerifal.cx> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14969 Archived-At: On Thu, Nov 28, 2019 at 04:56:42PM -0500, Rich Felker wrote: > Work on the new malloc is well underway, and I have a draft version > now public at: > > https://github.com/richfelker/mallocng-draft > > Some highlights: And some updates: Since posting this, I've found and fixed some bugs. One thing I'm really happy about is that I didn't have to wade through any application-level memory corruption. Aside from issues from compilers doing bad things without -ffreestanding, and the MAP_FAILED issue I never actually hit, all of them were caught as assertion failure traps. This is very different from my experience developing the old malloc in musl, and suggests good coverage for consistency checking which is tied to hardening. (Note: some of the consistency checks are probably overzealous and unrelated to likely attack vectors, and may make sense to disable later to improve performance.) So now, as of: https://github.com/richfelker/mallocng-draft/commits/afc39b01c82100cbb3f343c6e0ca1bc963e4ce23 it's now working to run (via LD_PRELOAD interposition) firefox, gimp, inkscape, and a number of less-demanding applications I've tried. I haven't done any rigorous testing, but at first glance firefox memory usage "seems" to be more stable, and varies up/down with usage rather than just going up. Strategy for creating new groups and how soon to reuse freed memory probably still has a lot of suboptimal properties, but I think the new allocator is usable/testable at this point. Rich