mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: Leesoo Ahn <yisooan@davolink.co.kr>
Cc: musl@lists.openwall.com
Subject: Re: [musl] Memory leak issue in multi-threaded program
Date: Wed, 5 Feb 2020 15:00:22 -0500	[thread overview]
Message-ID: <20200205200022.GD1663@brightrain.aerifal.cx> (raw)
In-Reply-To: <90bd03c7-5b8a-7761-130a-35a77303df37@davolink.co.kr>

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

      reply	other threads:[~2020-02-05 20:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-28  5:44 Leesoo Ahn
2020-01-28 13:29 ` Rich Felker
2020-01-29  1:55   ` Leesoo Ahn
2020-02-05 10:17   ` Leesoo Ahn
2020-02-05 20:00     ` Rich Felker [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200205200022.GD1663@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    --cc=yisooan@davolink.co.kr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).