From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12485 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [RFC] malloc + threads = memleak? Date: Fri, 9 Feb 2018 10:00:26 -0500 Message-ID: <20180209150026.GI1627@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1518188348 32165 195.159.176.226 (9 Feb 2018 14:59:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 9 Feb 2018 14:59:08 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-12501-gllmg-musl=m.gmane.org@lists.openwall.com Fri Feb 09 15:59:04 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1ekA8K-0006VJ-RP for gllmg-musl@m.gmane.org; Fri, 09 Feb 2018 15:58:36 +0100 Original-Received: (qmail 9563 invoked by uid 550); 9 Feb 2018 15:00:40 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 9540 invoked from network); 9 Feb 2018 15:00:39 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12485 Archived-At: On Fri, Feb 09, 2018 at 04:33:38PM +0200, Roman Yeryomin wrote: > Hello! > > I have a very easy reproducible memory leak here when using > malloc/free in two threads. > Attaching a simple test. > thread() here is calling pthread_create(): > https://github.com/yeryomin/liba/blob/master/liba.c#L181 > > Do I misunderstand something or is it a bug? > This can be avoided by wrapping malloc into locks but not sure if > that's the fix you want... I haven't looked at this in detail yet, but I suspect this is a known issue that I thought was hard to hit, and that you've just found a reliable way to reproduce. I'll investigate more in a bit. I think it may turn out to be impossible to fix without either making malloc noticably slower or overhauling the whole malloc implementation (which is planned but I'm not ready to do yet). Thanks for the report; this looks like it will be useful even if disappointing. Rich