[Bug 2119376] [NEW] program starts with printf("a"); fflush(stdout); yet doesnt echo anything

Richard Biswas 2119376 at bugs.launchpad.net
Sat Aug 2 18:14:49 UTC 2025


Public bug reported:

I have pared down a meaningful program to a contrived minimal program debug.c which begins with a memory allocation, and then via a macro does
printf("%s", "a" ); fflush( stdout) ;
and if the program is called with an existing file as command line argument, it doesnt echo anything at all, which is the bug.

whereas if called with a nonexisting file as command line argument, it always echos correctly.
when in all cases it should echo "a" and then maybe other stuff.
there is an fread() command later, if I comment that out, then it does echo "a" properly. it is a totally illogical and mystifying bug that I have wasted many hours and concluded its a very low level bug with gcc.

commenting out the fread later, shouldnt change what it echoes earlier,
totally crazy!

I have arranged the various requested files, namely deb-debug.i, the
self contained source file debug.c and the output of "gcc -v -save-temps
debug.c -o deb.exe". to replicate the bug, use the following shell
commands, where no other file needed to do this other than debug.c,
compiled to deb.exe, example1.txt created by the simple shell command.
The supplied "gcc -v -save-temps" file was done as a second compilation.

$ echo hello >example1.txt
$
$ gcc debug.c -o deb.exe
$
$ ./deb.exe example1.txt
$
$ ./deb.exe example1.tx
acouldnt open "example1.tx"
$
$

where when the program is run with example1.txt as argument, with the file created via the echo command, then the program echos nothing at all, which is a bug as it should echo 'a' at least, and no errors at all compiling it. Then when I run it with nonexisting "example1.tx", then it echoes correctly: acouldnt open "example1.tx"
where the initial 'a' is the expected echo

something really strange and pathological and low level going on!

this is all on Linux Mint 64 bit, and I am using the most up to date
gcc. the file with the output of "gcc -v -save-temps" gives the full
info as to gcc and Mint version.

I should point out my PC has more than 90Gig of memory, so there should
be no problem with the memory allocation, and I have written lots of
other programs which make even bigger memory allocations without
problem. And that memory allocation occurs when the nonexistent file is
given, so the problem isnt with the memory allocation, which in fact
originally was later, I just moved it earlier to construct a minimal
problem source file. but the fread() seems to be causing the mayhem, as
when that is commented out then the program echos correctly. But that
doesnt make any sense that a later action causes the earlier code to
malfunction. also no core dumps at all.

** Affects: gcc-11 (Ubuntu)
     Importance: Undecided
         Status: New

** Attachment added: "the self contained source file debug.c"
   https://bugs.launchpad.net/bugs/2119376/+attachment/5896105/+files/debug.c

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to gcc-11 in Ubuntu.
https://bugs.launchpad.net/bugs/2119376

Title:
  program starts with printf("a");fflush(stdout);yet doesnt echo
  anything

Status in gcc-11 package in Ubuntu:
  New

Bug description:
  I have pared down a meaningful program to a contrived minimal program debug.c which begins with a memory allocation, and then via a macro does
  printf("%s", "a" ); fflush( stdout) ;
  and if the program is called with an existing file as command line argument, it doesnt echo anything at all, which is the bug.

  whereas if called with a nonexisting file as command line argument, it always echos correctly.
  when in all cases it should echo "a" and then maybe other stuff.
  there is an fread() command later, if I comment that out, then it does echo "a" properly. it is a totally illogical and mystifying bug that I have wasted many hours and concluded its a very low level bug with gcc.

  commenting out the fread later, shouldnt change what it echoes
  earlier, totally crazy!

  I have arranged the various requested files, namely deb-debug.i, the
  self contained source file debug.c and the output of "gcc -v -save-
  temps debug.c -o deb.exe". to replicate the bug, use the following
  shell commands, where no other file needed to do this other than
  debug.c, compiled to deb.exe, example1.txt created by the simple shell
  command. The supplied "gcc -v -save-temps" file was done as a second
  compilation.

  $ echo hello >example1.txt
  $
  $ gcc debug.c -o deb.exe
  $
  $ ./deb.exe example1.txt
  $
  $ ./deb.exe example1.tx
  acouldnt open "example1.tx"
  $
  $

  where when the program is run with example1.txt as argument, with the file created via the echo command, then the program echos nothing at all, which is a bug as it should echo 'a' at least, and no errors at all compiling it. Then when I run it with nonexisting "example1.tx", then it echoes correctly: acouldnt open "example1.tx"
  where the initial 'a' is the expected echo

  something really strange and pathological and low level going on!

  this is all on Linux Mint 64 bit, and I am using the most up to date
  gcc. the file with the output of "gcc -v -save-temps" gives the full
  info as to gcc and Mint version.

  I should point out my PC has more than 90Gig of memory, so there
  should be no problem with the memory allocation, and I have written
  lots of other programs which make even bigger memory allocations
  without problem. And that memory allocation occurs when the
  nonexistent file is given, so the problem isnt with the memory
  allocation, which in fact originally was later, I just moved it
  earlier to construct a minimal problem source file. but the fread()
  seems to be causing the mayhem, as when that is commented out then the
  program echos correctly. But that doesnt make any sense that a later
  action causes the earlier code to malfunction. also no core dumps at
  all.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gcc-11/+bug/2119376/+subscriptions




More information about the foundations-bugs mailing list