From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4741 Path: news.gmane.org!not-for-mail From: u-igbb@aetey.se Newsgroups: gmane.linux.lib.musl.general Subject: malloc not behaving well when brk space is limited? Date: Sat, 29 Mar 2014 17:00:32 +0000 Message-ID: <20140329170032.GJ8221@example.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 1396112473 24379 80.91.229.3 (29 Mar 2014 17:01:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 29 Mar 2014 17:01:13 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4745-gllmg-musl=m.gmane.org@lists.openwall.com Sat Mar 29 18:01:08 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 1WTwd1-0004IE-Io for gllmg-musl@plane.gmane.org; Sat, 29 Mar 2014 18:01:07 +0100 Original-Received: (qmail 20395 invoked by uid 550); 29 Mar 2014 17:01: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 20387 invoked from network); 29 Mar 2014 17:01:03 -0000 X-T2-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_50 Received-SPF: none receiver=mailfe08.swip.net; client-ip=77.247.181.164; envelope-from=u-igbb@aetey.se Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:4741 Archived-At: Hello, Background: Compiling a native musl-based toolchain for ia32 on Linux 2.6+. Using the standalone dynamic loader mode. (The latter seems to lead to a quite limited heap space, by kernel behaviour/design) I encounter out of memory errors. A look at the malloc source does not find any fallback to mmap when heap is exhausted. What would you suggest as a suitable approach to make it work? Somebody has possibly already encountered and solved this with musl? I see also reports about a related out of memory problem with pae-executables which means a solution might help many musl users. The other standard libraries I am using (glibc, uclibc) seem to happily switch to allocation from mmap() when the heap is full. I understand that this costs some code and performance but a breakup is no good either. Any ideas? Maintaining and using an external libmalloc or substituting malloc in musl? This feels like quite a burden... (Would musl internal calls to malloc notice the external library and resolve to its entry points instead of the internal malloc?) Rune