geninfo chokes on files names '$x/.._filename.c.gcda'

[EvanTheB]

geninfo tests/flashrom_unit_tests.p/

Processing flashrom_unit_tests.p/.._flashrom.c.gcda
geninfo: WARNING: GCOV did not produce any data for flashrom/buildcov/tests/flashrom_unit_tests.p/.._flashrom.c.gcda

gcov tests/flashrom_unit_tests.p/.._flashrom.c.o

File '../flashrom.c'
Lines executed:54.73% of 771
Creating 'flashrom.c.gcov'

File '../include/programmer.h'
Lines executed:0.00% of 6
Creating 'programmer.h.gcov'

Lines executed:54.31% of 777

Files with this strange name are produced by meson build system, there are many bugs around about this for meson projects, but I didn't find one here on lcov which seems to be the source of the bug.

mesonbuild/meson#6747

mesonbuild/meson#9844

linux-nvme/libnvme#393

[henry2cox]

Maybe not the answer you are looking for:

• which gcc version are you using?
• can you try the fork mentioned in PR Differential coverage, date and owner binning - plus a few minor enhancements and refactoring (was "Diffcov initial") #86 - and add "--debug --debug" to your geninfo command (so it will tell you what it is doing and which files it found)
  At that point, it may be possible to figure out what files got skipped (if any) - and then figure out why.

As you say: it was probably unwise to use filename that begin with ".." or ".".

[EvanTheB]

gcc (Debian 12.2.0-3) 12.2.0

geninfo: LCOV version 1.16-3-g92e2121

Here is a log from the TOT lcov;
stderr.txt
stdout.txt

Rerunning one of the gcov lines that claims to find no data:

gcov /usr/local/google/home/evanbenn/chromiumos/src/third_party/flashrom/buildcov/tests/flashrom_unit_tests.p/.._flashrom.c.gcda -b -x -i
File '../flashrom.c'
Lines executed:55.54% of 902
Branches executed:69.86% of 564
Taken at least once:42.91% of 564
Calls executed:47.06% of 272

File '../include/programmer.h'
Lines executed:0.00% of 6
Branches executed:0.00% of 8
Taken at least once:0.00% of 8
No calls

Creating '.._flashrom.c##9c7f61132e0c1c878d31795c8030c0d7.gcov.json.gz'
Lines executed:55.18% of 908

[EvanTheB]

Logs from running off #169 instead of TOT as requested.

stderr.txt
stdout.txt

[henry2cox]

Thanks...
Could you send along the gcov output file you generated, above?
I suspect that gcov 12.2 puts something new in the output that the current code doesn't understand.

The other thing to check is whether that output file matches the intermediate generated by the call contained in geninfo.
(I have no reason to think it does not match - just covering bases. I suspect that we won't learn anything from this part of the experiment.)
To check that: please add "--preserve" to your geninfo command line.
You can also specify "--tempdir pwd/temp" so that the intermediates don't go into a hard-to-find randomly named directory in /tmp. I think that that directory has to already exist, and I think you need to use a fully qualified path.

The first part (the gcov file content) is more important than the second.

Thanks

Henry

[henry2cox]

Hi -
I started going back to look at potential bugs.
Could you use the current lcov TOT and rerun your example (it will fail the same way it did before - TOT is very similar to #169 that you already tried).
At that point, in your output log, you will find lines of the form:

DEBUG: system(gcov /usr/local/google/home/evanbenn/chromiumos/src/third_party/flashrom/buildcov/tests/flashrom_unit_tests.p/.._ch341a_spi.c.gcda -b -x -i)
geninfo: WARNING: GCOV did not produce any data for /usr/local/google/home/evanbenn/chromiumos/src/third_party/flashrom/buildcov/tests/flashrom_unit_tests.p/.._ch341a_spi.c.gc
Please run that gcov command (in your shell) - and then sent/attach/upload the "*.gcov" output file from that command.
There is something in that file which lcov/geninfo does not like...but I can't reproduce to debug.
Thanks
Henry
da

[EvanTheB]

run on e4a480f

stdout.txt
stderr.txt

[henry2cox]

Hi -
Could you run the command:
gcov /usr/local/google/home/evanbenn/chromiumos/src/third_party/flashrom/buildcov/tests/flashrom_unit_tests.p/.._writeprotect_ranges.c.gcda -b -x -i
in your environment, then execute
find . -name ".gcov"
and then attach the file or files you find.
I haven't been able to reproduce the issue - so I need the data files from your environment to see if I can figure out the bug.
(This may or may not be sufficient and I may need more data and/or more experiments in the future. Please accept my apologies in advance.)
Thanks
Henry

[henry2cox]

I think that I finally figured out the issue and that it is fixed in 238ea7c.
Could you to download the fixand let me know if there are more issues or to close this issue if you think that it is resolved.

Sorry for the delays.
Henry

[EvanTheB]

Here is a repro:

> echo "int main () { return 0; }" > .._main.c
> make CFLAGS="-fprofile-arcs -ftest-coverage" .._main
> ./.._main

> gcov .._main.gcda -b -x -i
File '.._main.c'
Lines executed:100.00% of 1
No branches
No calls

Creating '.._main##5002bdbb498819c0bd8947d04983c74b.gcov.json.gz'
Lines executed:100.00% of 1

> geninfo .
Found gcov version: 12.2.0
Using intermediate gcov format
Using JSON module JSON::XS
Scanning . for .gcda files ...
Found 1 data files in .
Processing .._main.gcda
geninfo: WARNING: GCOV did not produce any data for /usr/local/google/home/evanbenn/code/experiments/gcov_bug/.._main.gcda
Finished .info-file creation

[EvanTheB]

this is fixed at TOT

[ledav-net]

Hi @EvanTheB,

I've the same issue with these errors: "geninfo: WARNING: GCOV did not produce any data for"...
You said, it's fixed at TOT... But what is "TOT" and where can I find a patch who fix this problem ?

Thanks in advance for your help.
David.

[henry2cox]

"Top of Tree" - that is, at head of 'master'.
The comment above suggests that it might have been fixed in 238ea7c - but the fix may be later than that - I did not try to check.
Easiest approach is to download the latest code and try it. If there is still a bug - please file an issue (with testcase) or reopen this one.
Hope this helps.
Henry

[ledav-net]

Hi Henry,

Thanks for this quick answer.

"Top of Tree"

Okayy :-)

that is, at head of 'master'. The comment above suggests that it might have been fixed in 238ea7c - but the fix may be later than that - I did not try to check. Easiest approach is to download the latest code and try it. If there is still a bug - please file an issue (with testcase) or reopen this one. Hope this helps. Henry

I tried already with the master branch but it din't fixed the issue... Maybe I did something wrong as it was a quick test...
I will give it a new try on Monday and keep you updated. Thanks again :-)

David.

[henry2cox]

Just a clarification:
It isn't an error (or, at least it is not an lcov error) for gcov to not produce data for some files. It does happen sometimes.
("TOT" lcov does warn when that happens, though.)

What is an lcov bug, is when the gcov data is NOT empty - but lcov does not grok.
Those are the bugs that I think are fixed (...but maybe not...we can demonstrate the presence of bugs, but cannot prove that there are none).

If we suspect an lcov bug, then the approach is to investigate the coverage data generated by the compiler.
If there is data present and we did not figure it out: there is a bug. Otherwise not. (Though possibly a gcc/gcov or llvm/llvm-cov bug - which should also be reported, if identified.)

[ledav-net]

Hi @henry2cox,

I've made some more tests today and it seems indeed fixed in Master but not in v1.16.
I'm searching which commit fix the issue to try to backport it to v1.14 or v1.16... If you have some clues, I would really appreciate.

David.

[henry2cox]

Hmm. Not so straightforward, I fear. The fix in 238ea7c is just to fix a bug that I had introduced related to recovery after finding an issue in the gcov data (empty file or whatever). The actual handling of the gcov/llvm-cov call and output parsing has changed a lot since 1.16. I think, not to easy to extract just the geninfo handling changes.

I think, maybe easier/better to use the TOT version for now - and wait for the lcov 2.0 release - which is likely "coming soon".
Using TOT will be no different than backporting in the sense that you would require a local/non-standard tool install in either case; if your IT guys are OK with the latter - then they should be OK with the former.

Sorry to be less than helpful.
Henry

[ledav-net]

I'll follow your advice. Thanks for your time answering me anyway, I much appreciated.

[ledav-net]

For the record, it seems that just changing the following 2 lines, fixes the issue with "geninfo: WARNING: GCOV did not produce any data for" in v1.16:

diff --git a/bin/geninfo b/bin/geninfo
index 31c0b57..e1e8f5d 100755
--- a/bin/geninfo
+++ b/bin/geninfo
@@ -2555,12 +2555,12 @@ sub process_intermediate($$$)
        }
 
        # Parse resulting file(s)
-       for my $gcov_filename (glob("*.gcov")) {
+       for my $gcov_filename (glob("*.gcov .*.gcov")) {
                read_intermediate_text($gcov_filename, \%data);
                unlink($gcov_filename);
        }
 
-       for my $gcov_filename (glob("*.gcov.json.gz")) {
+       for my $gcov_filename (glob("*.gcov.json.gz .*.gcov.json.gz")) {
                read_intermediate_json($gcov_filename, \%data, \$json_basedir);
                unlink($gcov_filename);
                $json_format = 1;

In case this helps someone...

[eli-schwartz]

Part of the problem here is that that linked commit states, in its commit message, that it fixes 4 different things spanning 150 lines. The problem in this specific issue is most likely fixed by a mere 10 of those lines.

Without a granular commit that fixes exactly one thing, it becomes much, much harder to backport a single fix.