From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5782 Path: news.gmane.org!not-for-mail From: Alexander Monakov Newsgroups: gmane.linux.lib.musl.general Subject: Replacing malloc Date: Fri, 8 Aug 2014 16:15:29 +0400 (MSK) Message-ID: 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 1407500233 31805 80.91.229.3 (8 Aug 2014 12:17:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Aug 2014 12:17:13 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5787-gllmg-musl=m.gmane.org@lists.openwall.com Fri Aug 08 14:17:06 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 1XFj6X-000255-Fq for gllmg-musl@plane.gmane.org; Fri, 08 Aug 2014 14:17:05 +0200 Original-Received: (qmail 20188 invoked by uid 550); 8 Aug 2014 12:17: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 20177 invoked from network); 8 Aug 2014 12:17:04 -0000 User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) Xref: news.gmane.org gmane.linux.lib.musl.general:5782 Archived-At: [changing topic, subject adjusted] On Fri, 8 Aug 2014, Rich Felker wrote: > The fourth issue is much bigger: replacing malloc is UB and does not > work, especially not on musl. :-) Whoa. Let me ask for further clarifications. You probably don't need me to tell you that most people expect that replacing malloc would in fact work, with at least two use cases in mind: a tracking wrapper around libc malloc (obtained via dlsym), or an entire custom allocator that obtains fresh memory via mmap. So you can LD_PRELOAD a "malloc debugging library" or preload or even link against an alternative allocator. Of course it's not without inherent issues. If the alternative allocator provides malloc/realloc/calloc/free, it's going to see an unexpected but legitimate free when the application passes pointer obtained via posix_memalign. Or when the application obtains a free()-able pointer via other libc functionality such as asprintf and the libc is linked in such a way that internal malloc calls are not interposable. Or on glibc a malloc wrapper needs to handle malloc->dlsym->malloc recursion. I hope above you didn't mean to say that anybody wishing to use malloc wrappers or custom mmap-based malloc replacements on musl should abandon all hope, period; but merely that it is not for production use, and attempting to do so should be with care, for instance if gnash library uses custom malloc, it may not return pointers to that memory to be free()'d by the main executable (calling libc's free). But it would be like that on any libc. So I have to wonder what "especially not on musl" stands for. But so far every time I speak about a problem with musl the problem is deeper than I initially think -- so please clarify :) Alexander