Re: make coverage-html on OS X - Mailing list pgsql-hackers

tl;dr: It's critical that you actually do a make install, or at least it 
is if you've set --prefix with configure. If you don't, then even if you 
do make check you'le going to get the *installed* libpq, and not the 
*built* libpq.

Also, looks like there's a race between the .info and .c.gcov targets 
with parallel make; I'm wondering if there's a way to fix that by not 
allowing parallelism in each directory...? (Presumably the issue is the 
rm *.gcov). It'd be nice to fix this because -j speeds up coverage-html 
a lot, even with just 2 cores.

On 10/27/16 9:38 PM, Peter Eisentraut wrote:
> On 10/27/16 1:27 PM, Jim Nasby wrote:
>> Well, that got me closer, but it's still blowing up on libpq:
>>
>> genhtml: ERROR: no valid records found in tracefile
>> ./src/interfaces/libpq/lcov.info
>
> I have seen similar problems when I use a gcov that does not match the gcc.

I switched back to macports gcc6, verified version correctness, and got 
further (though still broken). Looking through the build log:

Processing fe-lobj.gcda
/Users/decibel/pgsql/HEAD/src/interfaces/libpq/fe-lobj.gcda:stamp 
mismatch with notes file
geninfo: WARNING: gcov did not create any files for 
/Users/decibel/pgsql/HEAD/src/interfaces/libpq/fe-lobj.gcda!
...
gcov -b -f -p -o .  fe-lobj.c >fe-lobj.c.gcov.out
./fe-lobj.gcda:stamp mismatch with notes file

First hit[1] on "google:gcov mismatch with notes file" led me to this 
hexdump command (picking a libpq file at random...)

hexdump -e '"%x\n"' -s8 -n4 fe-lobj.gcda
6929786
hexdump -e '"%x\n"' -s8 -n4 fe-lobj.gcno
d93a160

Second hit[2] gives a better explaination: the files were rebuilt a 
second time. While I don't see that happening in the log, his example is 
from building a shared library, so I'm wondering if that's got something 
to do with this.

I went into src/interfaces/libpq, did rm *.gc* lcov.info. After doing 
that, a second run of make coverage-html worked fine.

I'm wondering if there's some magic involved in coverage with shared 
libraries...

Actually, after a bunch of other experiments I ran those hexdump 
commands again; the value for .gcno has changed, but the value for .gcda 
hasn't. So I'm wondering if the base system libpq is getting pulled in. 
Sure enough, if I also do make install the timestamp matches. Presumably 
this is all due to having set --prefix with configure.

> I was able to run it successfully using CC=gcc-6 and GCOV=gcov-6 from
> Homebrew.

I tried that as well; it didn't work either. I didn't run a diff, but it 
appeared to be doing the same thing that macports gcc6 was.

1: 
http://stackoverflow.com/questions/27276155/gcov-generates-empty-coverage-for-c
2: http://stackoverflow.com/a/26061575/4196282
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461