* Probable bug
@ 2023-07-30 9:38 natan_b
2023-07-30 11:29 ` Eliot Moss
0 siblings, 1 reply; 5+ messages in thread
From: natan_b @ 2023-07-30 9:38 UTC (permalink / raw)
To: cygwin
[-- 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
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Probable bug
2023-07-30 9:38 Probable bug natan_b
@ 2023-07-30 11:29 ` Eliot Moss
2023-07-30 11:37 ` Takashi Yano
0 siblings, 1 reply; 5+ messages in thread
From: Eliot Moss @ 2023-07-30 11:29 UTC (permalink / raw)
To: natan_b, cygwin
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
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Probable bug
2023-07-30 11:29 ` Eliot Moss
@ 2023-07-30 11:37 ` Takashi Yano
2023-07-31 9:41 ` Takashi Yano
0 siblings, 1 reply; 5+ messages in thread
From: Takashi Yano @ 2023-07-30 11:37 UTC (permalink / raw)
To: cygwin; +Cc: moss
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>
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Probable bug
2023-07-30 11:37 ` Takashi Yano
@ 2023-07-31 9:41 ` Takashi Yano
2023-08-01 8:59 ` Takashi Yano
0 siblings, 1 reply; 5+ messages in thread
From: Takashi Yano @ 2023-07-31 9:41 UTC (permalink / raw)
To: cygwin
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>
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Probable bug
2023-07-31 9:41 ` Takashi Yano
@ 2023-08-01 8:59 ` Takashi Yano
0 siblings, 0 replies; 5+ messages in thread
From: Takashi Yano @ 2023-08-01 8:59 UTC (permalink / raw)
To: cygwin
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>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-08-01 8:59 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-07-30 9:38 Probable bug natan_b
2023-07-30 11:29 ` Eliot Moss
2023-07-30 11:37 ` Takashi Yano
2023-07-31 9:41 ` Takashi Yano
2023-08-01 8:59 ` Takashi Yano
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 read-only IMAP folder(s) and NNTP newsgroup(s).