[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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[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
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.
