From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RDNS_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 23430 invoked from network); 10 Mar 2020 11:09:25 -0000 Received-SPF: pass (mother.openwall.net: domain of lists.openwall.com designates 195.42.179.200 as permitted sender) receiver=inbox.vuxu.org; client-ip=195.42.179.200 envelope-from= Received: from unknown (HELO mother.openwall.net) (195.42.179.200) by inbox.vuxu.org with ESMTP; 10 Mar 2020 11:09:25 -0000 Received: (qmail 11577 invoked by uid 550); 10 Mar 2020 11:09:20 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 11552 invoked from network); 10 Mar 2020 11:09:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=avast.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=r6hS6CV3L2JZ0tOLOTffQ/RaXsQCbK7wOMrwWKWceAo=; b=nPYOuDeQ8o/qrTwJp+hHqfJpS2p2Zk59Q3+Q0QZshenoFkoLDAQAS1pDtYj3DQmS4z fsfVg9wQlZrKZAloqE4BbRrGQ8GLuUv26Z3BBltprcvCDZFreRnCMbyRKuHncURxAoUZ Ob2agmYsBtxdblSRYD6sVD4oBQzYk91MmJWzQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=r6hS6CV3L2JZ0tOLOTffQ/RaXsQCbK7wOMrwWKWceAo=; b=QTngw2h3P0sNYTOE6Qp2REFWrIZz4JeCUmhUWm95WIfu0NixsQNCHmlF6GY/0CbKh7 i/qFGD26lH9j40sSzyfDX+JA9OEDlkbCFwg+GzWmQh4FdGgpQgzxLKf+GYOrj09ucOcA qVjJN/Asj4NvVQrKyI6fC5hcIs6iQEdlu1Id3wfwu7EHxjYY7R6gswpPfuI5MuBjuQm9 wA2ay7BAq7aQM1ug5sOmoniN4aqbbLFBzfcMLJJHrczt27YUPLKjhn9WUK3Pe+Ag8y+y oGsjJwfnYTvaWFSLtdx163iCmPYeuLbT7pfW5+SL2fo2IkA9o5VOhhsoplh+/wWfYAQq Vn9g== X-Gm-Message-State: ANhLgQ1npZlNNIXYBekqRB65N8Gl7px5GiUV85lryH8oR9mQgfySfDpF 8+21qmhXQEA6bXNpAw7hKRJOx6armhU+9f+Jn7VaUkjG4Rv+TA== X-Google-Smtp-Source: ADFU+vtwmchKUXKgAxsNIA22bikQ/PwxSdmMBA2WJfuRCRFQa8AkPW8leLUtmZ5nMr6o9zr9zGEc85VzRJwlxaeiYyA= X-Received: by 2002:a2e:b246:: with SMTP id n6mr12540322ljm.70.1583838548141; Tue, 10 Mar 2020 04:09:08 -0700 (PDT) MIME-Version: 1.0 References: <20200310095949.GJ14278@port70.net> In-Reply-To: <20200310095949.GJ14278@port70.net> From: "Kaisrlík, Jan" Date: Tue, 10 Mar 2020 12:08:57 +0100 Message-ID: To: musl@lists.openwall.com, Kaisrlík@port70.net, Jan Content-Type: multipart/alternative; boundary="0000000000000ba0a805a07e266a" Subject: Re: [musl] musl and jemalloc support --0000000000000ba0a805a07e266a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Tue, Mar 10, 2020 at 10:59 AM Szabolcs Nagy wrote: > * Kaisrlík, Jan [2020-03-10 10:32:08 +0100]: > > I would like to ask about the support of external malloc and jemalloc. > > I find an old mail in ML claiming that support is not there and using > > external malloc function can potentially cause problems[1] and a > > thread[2] on jemalloc saying the same. On the other hand, I find a lot > > of pages comparing speed like pages [3] and also I noticed that Musl > > claims "replacement of malloc is now allowed/supported" statement in > > changelog [4]. So, my expectation is Musl from version 1.1.20 supports > > the loading of external malloc function and it is working. Is my > > assumption correct? Does it have any limitations, e.g., it has to be > > done in compilation time, is LD_PRELOAD supported? > > yes, it just works. > Thank you for your answer. Glad to hear that. > > > > > The reason why I'm asking is that some apps started crashing with a > > weird coredump from the moment I used > > LD_PRELOAD=/usr/lib/libjemalloc.so.2:/usr/lib/libpthread.so. > > the preloaded libraries obviously have to be built against musl. > (in some cases a glibc linked library would work, i would expect > a glibc linked malloc library to work with musl on x86_64, but > there is no guarantee) > All my components are built against musl for armv7 architecture. > > the fact that you have libpthread.so means it's not a musl system > and preloading a libpthread.so from another libc is expected to > crash. (even on other systems you should not just preload libpthread, > but libjemalloc should have it in its dependencies if needed.) > Sorry, I kept libpthread from one of my previous tests which is slightly misleading in this case. My system has only one libpthread library coming from musl. > > > > > Thank you for your answer. > > > > The best, > > Jan > > > > [1]: https://www.openwall.com/lists/musl/2014/08/08/11 > > [2]: https://github.com/jemalloc/jemalloc/issues/1443 > > [3]: > https://users.rust-lang.org/t/optimizing-rust-binaries-observation-of-musl-versus-glibc-and-jemalloc-versus-system-alloc/8499/7 > > [4]: https://git.musl-libc.org/cgit/musl/tree/WHATSNEW#n1916 > --0000000000000ba0a805a07e266a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit

On Tue, Mar 10, 2020 at 10:59 AM Szabolcs Nagy <nsz@port70.net> wrote:
* Kaisrlík, Jan <jan.kaisrlik@avast.com> [2020-03-10 10:32:08 +0100]:
> I would like to ask about the support of external malloc and jemalloc.
> I find an old mail in ML claiming that support is not there and using
> external malloc function can potentially cause problems[1] and a
> thread[2] on jemalloc saying the same. On the other hand, I find a lot
> of pages comparing speed like pages [3] and also I noticed that Musl
> claims "replacement of malloc is now allowed/supported" statement in
> changelog [4]. So, my expectation is Musl from version 1.1.20 supports
> the loading of external malloc function and it is working. Is my
> assumption correct? Does it have any limitations, e.g., it has to be
> done in compilation time, is LD_PRELOAD supported?

yes, it just works.

Thank you for your answer.  Glad to hear that.
 

>
> The reason why I'm asking is that some apps started crashing with a
> weird coredump from the moment I used
> LD_PRELOAD=/usr/lib/libjemalloc.so.2:/usr/lib/libpthread.so.

the preloaded libraries obviously have to be built against musl.
(in some cases a glibc linked library would work, i would expect
a glibc linked malloc library to work with musl on x86_64, but
there is no guarantee)

All my components are built against musl for armv7 architecture.
 

the fact that you have libpthread.so means it's not a musl system
and preloading a libpthread.so from another libc is expected to
crash. (even on other systems you should not just preload libpthread,
but libjemalloc should have it in its dependencies if needed.)

Sorry, I kept libpthread from one of my previous tests which is slightly misleading in this case. My system has only one libpthread library coming from musl.
 

>
> Thank you for your answer.
>
> The best,
> Jan
>
> [1]: https://www.openwall.com/lists/musl/2014/08/08/11
> [2]: https://github.com/jemalloc/jemalloc/issues/1443
> [3]: https://users.rust-lang.org/t/optimizing-rust-binaries-observation-of-musl-versus-glibc-and-jemalloc-versus-system-alloc/8499/7
> [4]: https://git.musl-libc.org/cgit/musl/tree/WHATSNEW#n1916






--0000000000000ba0a805a07e266a--