Date: Sun, 16 Aug 2020 12:55:56 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: Restrictions on child context after multithreaded fork On Sun, Aug 16, 2020 at 09:05:28AM +0200, Pirmin Walthert wrote: > Dear Rich, > >I've seen suspicions that the switch to mallocng exposed this, but I'm > >pretty sure it was: > > > >https://git.musl-libc.org/cgit/musl/commit/?id=e01b5939b38aea5ecbe41670643199825874b26c > > I needed to patch asterisk because of similar issues (you gave me > some hints on this mailing list after I'd described the issue): > > https://issues.asterisk.org/jira/browse/ASTERISK-28776 > > However this happened with a combination of musl 1.2.0, which did > not have the mentioned commit applied, and mallocng (LD_PRELOAD > method). Asterisk with 1.2.0 and old malloc was running just fine. Yes, if you were using mallocng out-of-tree it doesn't integrate with musl's internal locking, and would always perform locks regardless of whether multithreaded. This is even stronger than the above-cited change. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.