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.0 required=5.0 tests=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 15594 invoked from network); 10 Mar 2020 10:00:07 -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 10:00:07 -0000 Received: (qmail 11867 invoked by uid 550); 10 Mar 2020 10:00:01 -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 11849 invoked from network); 10 Mar 2020 10:00:01 -0000 Date: Tue, 10 Mar 2020 10:59:49 +0100 From: Szabolcs Nagy To: musl@lists.openwall.com Cc: Kaisrlík@port70.net, Jan Message-ID: <20200310095949.GJ14278@port70.net> Mail-Followup-To: musl@lists.openwall.com, Kaisrlík@port70.net, Jan References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [musl] musl and jemalloc support * Kaisrl=C3=ADk, 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. >=20 > The reason why I'm asking is that some apps started crashing with a > weird coredump from the moment I used > LD_PRELOAD=3D/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) 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.) >=20 > Thank you for your answer. >=20 > The best, > Jan >=20 > [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-o= f-musl-versus-glibc-and-jemalloc-versus-system-alloc/8499/7 > [4]: https://git.musl-libc.org/cgit/musl/tree/WHATSNEW#n1916