Probable bug

Probable bug

[natan_b]

[-- Attachment #1: Type: text/plain, Size: 347 bytes --]

Hi Guys

very short.

prog.c

#include <stdio.h>
 
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!
 
Regards
natanb
 

Re: Probable bug

[Eliot Moss]

On 7/30/2023 5:38 AM, natan_b--- via Cygwin wrote:
> Hi Guys
> 
> very short.
> 
> prog.c
> 
> #include <stdio.h>
>   
> 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 ...

Regards - EM

Re: Probable bug

[Takashi Yano]

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 <stdio.h>
> >   
> > 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. :-(

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: Probable bug

[Takashi Yano]

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 <stdio.h>
> > >   
> > > 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 <takashi.yano@nifty.ne.jp>
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 <takashi.yano@nifty.ne.jp>

Re: Probable bug

[Takashi Yano]

On Mon, 31 Jul 2023 18:41:06 +0900
Takashi Yano wrote:
> 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 <stdio.h>
> > > >   
> > > > 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 <takashi.yano@nifty.ne.jp>
> 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.

I have just posted a patch for this issue to newlib mailing list.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>