[Bug gcov-profile/58602] .gcno files not truncated at gcov_close

[gbanks at sgi dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58602

Greg Banks  changed:

   What|Removed |Added

 CC||gbanks at sgi dot com

--- Comment #1 from Greg Banks  ---
This bug can affect users of ggcov (http://ggcov.sf.net), which reads
the .gcno files directly rather than running any gcc code.  Usually the
problem is harmless, as ggcov complains and stops parsing because it
tries to read random leftover bytes as a gcov tag.  However it's possible
that other subtle problems can creep in, like lines being double-counted.

The bug appears to have been introduced in this commit

http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8ab576411b46496e6baf77ba1aed1f38b6c818cd

which nine years ago (!) changed the actual code path taken from
an fopen("wb") to an open(O_RDWR|O_CREAT) plus an fdopen().  One
of the differences between those is that the old code had the side
effect of truncating an existing file, and the new code doesn't.

It looks like every version of gcc since 3.4 is affected.

[Bug gcov-profile/58602] .gcno files not truncated at gcov_close

[gbanks at sgi dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58602

--- Comment #2 from Greg Banks  ---
Created attachment 31085
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31085&action=edit
source for test case

Here's a test case which doesn't rely on optimisation behaviour
to demonstrate the bug.

me@machine 2603> gcc --coverage -c foo.c

me@machine 2604> ls -l foo.gcno
-rw-rw-r-- 1 gnb gnb 420 Oct 23 22:18 foo.gcno
 ^^^

me@machine 2605> gcc --coverage -DMAKE_ME_SMALLER -c foo.c

me@machine 2606> ls -l foo.gcno
-rw-rw-r-- 1 gnb gnb 420 Oct 23 22:19 foo.gcno
 ^^^
 # new file is incorrectly not smaller

me@machine 2607> rm foo.gcno
me@machine 2608> gcc --coverage -DMAKE_ME_SMALLER -c foo.c

me@machine 2609> ls -l foo.gcno
-rw-rw-r-- 1 gnb gnb 216 Oct 23 22:19 foo.gcno
 ^^^
 # this is the real size of the new file