Date: Wed, 5 Feb 2020 15:00:22 -0500 From: Rich Felker <dalias@...c.org> To: Leesoo Ahn <yisooan@...olink.co.kr> Cc: musl@...ts.openwall.com Subject: Re: 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. > > 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
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.