From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4758 Path: news.gmane.org!not-for-mail From: u-igbb@aetey.se Newsgroups: gmane.linux.lib.musl.general Subject: Re: Proposed approach for malloc to deal with failing brk Date: Mon, 31 Mar 2014 09:44:21 +0200 Message-ID: <20140331074421.GA30395@example.net> References: <20140331004104.GA15223@brightrain.aerifal.cx> <20140331043247.GC26358@brightrain.aerifal.cx> 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 1396251890 17374 80.91.229.3 (31 Mar 2014 07:44:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 31 Mar 2014 07:44:50 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4762-gllmg-musl=m.gmane.org@lists.openwall.com Mon Mar 31 09:44:45 2014 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 1WUWtg-00010a-V7 for gllmg-musl@plane.gmane.org; Mon, 31 Mar 2014 09:44:45 +0200 Original-Received: (qmail 26131 invoked by uid 550); 31 Mar 2014 07:44:43 -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 26123 invoked from network); 31 Mar 2014 07:44:42 -0000 X-T2-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_50 Received-SPF: none receiver=mailfe08.swip.net; client-ip=178.217.187.39; envelope-from=u-igbb@aetey.se Content-Disposition: inline In-Reply-To: <20140331043247.GC26358@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:4758 Archived-At: Hello Rich, On Mon, Mar 31, 2014 at 12:32:48AM -0400, Rich Felker wrote: > > Perhaps the best part is that this solution can be implemented in just > > a few lines of code. > > And here's the patch. Please test and let me know if this works. Extremely appreciated (and a nice approach indeed, as far as I can see). Now rebuilding a bunch of programs (including the gcc compiler itself) with a gcc which uses the patched musl and so far it seems to work. I guess this exercises malloc quite a bit. (Under the gcc stages rebuilding, the loader is used implicitly and presumably the heap exhaustion is not triggered, this confirms that the patch did not damage the brk mode of operation. The compiler seems otherwise to be capable of building everything I throw at it, while being run via the standalone loder, which previously failed due to "no memory") You saved my day, thanks Rich. Rune