From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id fa7d2b02 for ; Wed, 5 Feb 2020 20:00:38 +0000 (UTC) Received: (qmail 3555 invoked by uid 550); 5 Feb 2020 20:00:36 -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 3535 invoked from network); 5 Feb 2020 20:00:36 -0000 Date: Wed, 5 Feb 2020 15:00:22 -0500 From: Rich Felker To: Leesoo Ahn Cc: musl@lists.openwall.com Message-ID: <20200205200022.GD1663@brightrain.aerifal.cx> References: <20200128132900.GE30412@brightrain.aerifal.cx> <90bd03c7-5b8a-7761-130a-35a77303df37@davolink.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <90bd03c7-5b8a-7761-130a-35a77303df37@davolink.co.kr> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Rich Felker Subject: Re: [musl] Memory leak issue in multi-threaded program On Wed, Feb 05, 2020 at 07:17:05PM +0900, Leesoo Ahn wrote: > Dear Rich, > > My coworker and I had been trying to solve this leak issue in > embedded system which is based on OpenWRT, ARM64 arch and currently > musl-1.1.16 for our product. However, musl-1.1.24 patch you referred > below, we figured out that backporting of the patch into 1.1.16 is > quite difficult by such problems, for examples, translation faults > raised, or in another way of without the patch, double-locking issue > in atomically calling malloc/free with this changes[1]. > > But not only in 1.1.16, but also 1.1.24 that we tested with, has the > same problems as well. So, we are currently like in the middle of > Sea without any foods. It has a big risk and so much dangerous for > our product. > > We are considering to keep 1.1.16 as our base in product, because > although in 1.1.24, a lot of bugs fixed, nobody can guarantee for > our product when we put 1.1.24 on it. > > Could you give us any ideas for fixing the issue in v1.1.16, please? > Ah, we are in so much pain... > > Or what do you think this case that all the time, all processes ask > to kernel via mmap syscall? Does this solve the issue...even though > it has bad performance...? > > I wish I can solve this problem sooner. Unconditional use of mmap may be okay, but it will significantly harm performance and increase memory usage (even a 10-byte allocation will consume 4k!) and it would require some review to make sure there are no assumptions that mmap is only used for larger sizes. Your approach with wrapping malloc and free with big global locks should be safe, but you also need to wrap realloc. (There are other functions but I think they all call malloc, free, or realloc as backends so just those three should suffice.) This is probably the easiest solution available to you. I don't think backporting the patch I showed you to 1.1.16 would be a lot of work, and I could send you a quote for it as a paid support service if you're interested. If you were using 1.1.20 or later, another option would be to just link in an alternate malloc implementation, but that is not supported and not safe in earlier versions of musl like 1.1.16. And trying to make it work without understanding why it's unsafe would be a recipe for really nasty subtle breakage. Rich