From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12687 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: tcmalloc compatibility Date: Tue, 10 Apr 2018 10:33:59 -0400 Message-ID: <20180410143359.GF3094@brightrain.aerifal.cx> References: <0ea267bf-ea3a-9810-be1a-50e71b6cfce1@denis.im> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1523370730 12458 195.159.176.226 (10 Apr 2018 14:32:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 10 Apr 2018 14:32:10 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-12702-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 10 16:32:06 2018 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.84_2) (envelope-from ) id 1f5uJZ-00037I-AU for gllmg-musl@m.gmane.org; Tue, 10 Apr 2018 16:32:05 +0200 Original-Received: (qmail 26102 invoked by uid 550); 10 Apr 2018 14:34:11 -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 26084 invoked from network); 10 Apr 2018 14:34:11 -0000 Content-Disposition: inline In-Reply-To: <0ea267bf-ea3a-9810-be1a-50e71b6cfce1@denis.im> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12687 Archived-At: On Tue, Apr 10, 2018 at 01:22:54PM +0300, Denis V. Razumovsky wrote: > Dear Sirs, > > Could you please be so kind to fix muls compatibility with tcmalloc > (libtcmalloc_minimal in particular). Seems that tcmalloc developers > can't fix all issues without  corresponding changes of musl. malloc interposition is undefined behavior (as is any interposition of standard functions), and is very difficult to actually support as an extension in a way that doesn't have lots of serious problems. This has been discussed before but I don't have links handy. I'll try to dig them up later. The glibc folks are also aware that it's broken (on glibc, it only works if you get lucky and follow unwritten rules) and would probably like a fix but it's not easy on their side either. > Small cite from tcmalloc bug-report: > > > >> Doesn't look like musl will ever support replacing their malloc for > dynamically linked musl. This claim doesn't seem to be well-justified. Myself and members of our community have written a lot on why existing malloc interposition hacks are broken, but there's also an interest in what would take to make it work, and I particularly am interested in this from a standpoint that musl's malloc is not very good, and that being able to dynamically interpose it would facilitate developing and testing a replacement. Note however that if malloc interposition is supported at some point, there will be a specification for constraints on the malloc implementation including what functions you can call from it (e.g. something like AS-safety), and bug reports for implementations that do things outside this spec (and thereby inherently can't work safely or reliably) will not be considered bugs. > All appropriate details you can find at the page: > > https://github.com/gperftools/gperftools/issues/693 > > > Because of this many important software can't be ported properly to > Alpine linux because they depends from libtcmalloc_minimal. This seems false. You can just remove tcmalloc from them and use the system malloc and they will work fine (possibly after patching out unnecessary calls into the internals of the malloc replacement, e.g. for debug/stats/etc.). Rich