From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dmta1004.nifty.com (mta-snd01004.nifty.com [106.153.227.36]) by sourceware.org (Postfix) with ESMTPS id 6B48F3858430 for ; Mon, 31 Jul 2023 09:41:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6B48F3858430 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 dmta1004.nifty.com with ESMTP id <20230731094106267.FEHY.19103.HP-Z230@nifty.com> for ; Mon, 31 Jul 2023 18:41:06 +0900 Date: Mon, 31 Jul 2023 18:41:06 +0900 From: Takashi Yano To: cygwin@cygwin.com Subject: Re: Probable bug Message-Id: <20230731184106.90479ed81692c3c3a9fd41a9@nifty.ne.jp> In-Reply-To: <20230730203735.7d94749b4f08a9de9cc3ca9f@nifty.ne.jp> References: <199362107.5561484.1690709920649@mail1.libero.it> <20230730203735.7d94749b4f08a9de9cc3ca9f@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=-4.2 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,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 Sun, 30 Jul 2023 20:37:35 +0900 Takashi Yano wrote: > On Sun, 30 Jul 2023 07:29:10 -0400 > Eliot Moss wrote: > > On 7/30/2023 5:38 AM, natan_b--- via Cygwin wrote: > > > Hi Guys > > > > > > very short. > > > > > > prog.c > > > > > > #include > > > > > > int main() > > > { > > > float a=1.283; > > > while(1) > > > printf( "%f", a ); > > > } > > > > > > run with > > > $ ./prog.exe >/dev/null > > > > > > in windows monitor process the process increase it's memory it arrive to many Gb. > > > It's not a machine problem, other PC have same problem. > > > > > > Same program in wsl and MSYS2 works well! > > > > This probably has to do with output buffering, and may happen even without > > the >/dev/null since there are no line ends in the output. It may work with > > stdbuf -o0 (as in: stdbuf -o0 ./prog.exe >/dev/null) but may cause the program > > to run more slowly (each character is sent to the device, when then immediately > > discards it). It would seem you're hoping for the internal libraries to > > recognize the case of writing to /dev/null ... > > I also suspected that, however, it was not correct. > > while (1) sprintf(buf, "%f\n", a); > > has the same problem. :-( I looked into this problem, and found the cause. This is the serious bug in the commit: commit a4705d387f7874f9a5de3ee67861773a17691643 Author: Takashi Yano Date: Wed Dec 1 06:11:32 2021 +0900 ldtoa: Import gdtoa from OpenBSD. - This patch uses gdtoa imported from OpenBSD if newlib configure option "--enable-newlib-use-gdtoa=no" is NOT specified. gdtoa provides more accurate output and faster conversion than legacy ldtoa, while it requires more heap memory. Please let me consider how to fix that. -- Takashi Yano