From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4746 Path: news.gmane.org!not-for-mail From: u-igbb@aetey.se Newsgroups: gmane.linux.lib.musl.general Subject: Re: malloc not behaving well when brk space is limited? Date: Sat, 29 Mar 2014 18:02:29 +0000 Message-ID: <20140329180229.GL8221@example.net> References: <20140329170032.GJ8221@example.net> <20140329191502.072c07f9@vostro> <20140329172212.GW26358@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 1396116183 29391 80.91.229.3 (29 Mar 2014 18:03:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 29 Mar 2014 18:03:03 +0000 (UTC) Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-4750-gllmg-musl=m.gmane.org@lists.openwall.com Sat Mar 29 19:02:58 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 1WTxan-0002YS-DF for gllmg-musl@plane.gmane.org; Sat, 29 Mar 2014 19:02:53 +0100 Original-Received: (qmail 5895 invoked by uid 550); 29 Mar 2014 18:02:52 -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 5887 invoked from network); 29 Mar 2014 18:02:52 -0000 X-T2-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_50 Received-SPF: none receiver=mailfe07.swip.net; client-ip=134.0.29.198; envelope-from=u-igbb@aetey.se Content-Disposition: inline In-Reply-To: <20140329172212.GW26358@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:4746 Archived-At: On Sat, Mar 29, 2014 at 01:22:12PM -0400, Rich Felker wrote: > On Sat, Mar 29, 2014 at 07:15:02PM +0200, Timo Teras wrote: > > musl does not support external malloc. musl internal calls to > > malloc() are not overridable. Ok. > > I think you need to fix kernel. Rewrite allocator in musl. Or add the Too bad I can not choose the kernel on all the computers where I want my applications to run. To the contrary I am building as portable applications as possible. Hardly this situation is out of scope of musl (?) > > fallback code to mmap - but dalias said it's "hard". Perhaps still > > should be still reconsidered. > > Unfortunately the approach I want to use with mmap seems to be what > glibc uses for its thread-local arenas, and it performs something like > 2 to 10 times worse than brk... So unless we can solve that, I don't > think it's a good option. It could be a fallback, but I still don't > want PIE binaries running that much slower just because the kernel is > doing something wacky and wrong. It is a _lot_ better to run an order of magnitude slower than to fail totally, isn't it? If you have any code doing mmap-fallback, I would be willing to test it and hopefully use. > We need a good solution for this problem but I don't have one yet. This looks like a showstopper. The applications do not work properly as-is and replacing malloc or adding mmap support from scratch by myself is a threshold too high, given the time constraints. :( In other words, a bad solution would be much better than no solution. Otherwise my impression from musl until now is excellent. Thanks for your work on it. Regards, Rune