From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dmta0016.nifty.com (mta-snd00011.nifty.com [106.153.226.43]) by sourceware.org (Postfix) with ESMTPS id 12C783858D39 for ; Wed, 2 Aug 2023 06:39:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 12C783858D39 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=nifty.ne.jp Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=nifty.ne.jp Received: from HP-Z230 by dmta0016.nifty.com with ESMTP id <20230802063903942.UPEI.103888.HP-Z230@nifty.com> for ; Wed, 2 Aug 2023 15:39:03 +0900 Date: Wed, 2 Aug 2023 15:39:04 +0900 From: Takashi Yano To: newlib@sourceware.org Subject: Re: [PATCH] newlib: Fix memory leak regarding gdtoa-based _ldtoa_r(). Message-Id: <20230802153904.297a5e45cd91334e2c106e41@nifty.ne.jp> In-Reply-To: References: <20230801085731.1831-1-takashi.yano@nifty.ne.jp> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, 1 Aug 2023 14:35:54 +0200 Corinna Vinschen wrote: > Hi Takashi, > > On Aug 1 17:57, Takashi Yano wrote: > > After the commit a4705d387f78, printf() for floating-point values > > causes a memory leak. The legacy _ldtoa_r() assumed the char pointer > > returned will be free'ed by Bfree(). However, gdtoa-based _ldtoa_r() > > returns the pointer returned by gdtoa() which should be free'ed by > > freedtoa(). Due to this issue, the caller of _ldtoa_r() fails to free > > the allocated char buffer. This is the cause of the said memory leak. > > https://cygwin.com/pipermail/cygwin/2023-July/254054.html > > > > With this patch, a new buffer is allocated using Balloc() and the > > buffer returned by gdtoa() is copied into it. Then, free the original > > buffer using freedtoa(). > > Basically this is ok. But the question is this. Isn't it possible > to redefine the allocator in gdtoa so that it uses a Balloced buffer > right away? Forinstance, by using overloading macros? That would > allow to get away without having to copy stuff... Thanks for the advice. I tried that. Please check v2 patch. -- Takashi Yano