mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: tcmalloc compatibility
Date: Tue, 10 Apr 2018 10:33:59 -0400	[thread overview]
Message-ID: <20180410143359.GF3094@brightrain.aerifal.cx> (raw)
In-Reply-To: <0ea267bf-ea3a-9810-be1a-50e71b6cfce1@denis.im>

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


  reply	other threads:[~2018-04-10 14:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-10 10:22 Denis V. Razumovsky
2018-04-10 14:33 ` Rich Felker [this message]
2018-04-10 14:45   ` Bobby Powers
2018-04-10 15:35     ` Rich Felker
     [not found]   ` <878t9vlzh1.fsf@mid.deneb.enyo.de>
2018-04-10 18:39     ` Rich Felker
2018-04-10 20:33     ` Szabolcs Nagy
2018-04-10 20:44       ` Rich Felker
2018-04-10 21:17         ` Szabolcs Nagy
2018-04-15 11:52           ` ardi
2018-04-16  4:19             ` Markus Wichmann
2018-04-16  4:40               ` Rich Felker
2018-04-18 20:35                 ` Rich Felker
2018-04-19 18:27                   ` Szabolcs Nagy
2018-04-19 19:11                     ` Rich Felker
2018-04-18 20:50       ` Florian Weimer
2018-04-18 21:06         ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180410143359.GF3094@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).