Repository navigation
C++ code coverage is broken #39303
Description
Activity
It's unlikely to be any of those commits. The other, more plausible, difference between
- https://ci.nodejs.org/view/Node.js%20Daily/job/node-test-commit-linux-coverage-daily/928/ e0ebc6b
- https://ci.nodejs.org/view/Node.js%20Daily/job/node-test-commit-linux-coverage-daily/929/ 84d6ce9
is that we started building with
ccache g++-8(nodejs/build#2684).Reacted by Rich TrottLogged into the machine and tried building manually without
ccache-- problem still exists (C++ coverage is 0%) with g++-8.gcovis$ gcov --version gcov (Ubuntu 5.5.0-12ubuntu1~16.04) 5.5.0 20171010 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.Testing (manually) with
GCOVenvironment variable set togcov-8.With
gcov-8I get errors fromgcovr:Finding source file corresponding to a gcov data file currdir /tmp/node/out gcov_fname ^#src#crypto#crypto_context.cc.gcov [' -', ' 0', 'Source', '../src/crypto/crypto_context.cc\n'] source_fname /tmp/node/out/Release/obj.target/libnode/src/crypto/crypto_context.gcda root /tmp/node/out/Release/obj.target fname /tmp/node/out/../src/crypto/crypto_context.cc Parsing coverage data for file /tmp/node/out/../src/crypto/crypto_context.cc Filtering coverage data for file /tmp/node/out/../src/crypto/crypto_context.cc Traceback (most recent call last): File "/tmp/node/out/../gcovr/scripts/gcovr", line 2415, in <module> process_datafile(file_, covdata, options) File "/tmp/node/out/../gcovr/scripts/gcovr", line 884, in process_datafile process_gcov_data(fname, covdata, abs_filename, options) File "/tmp/node/out/../gcovr/scripts/gcovr", line 616, in process_gcov_data covered[lineno] = int(segments[0].strip()) ValueError: invalid literal for int() with base 10: '885*' Makefile:241: recipe for target 'coverage-test' failedI think we'd need a
gcovrupdate (currently pinned at 3.4:
) because of gcovr/gcovr#226, which was fixed by gcovr/gcovr#228 in gcov 4. There's a slight complication there as gcov 4 and later need to be installed viaLines 223 to 224 in c6d9d8a
if [ ! -d gcovr ]; then git clone -b 3.4 --depth=1 \ --single-branch https://github.com/gcovr/gcovr.git; fi pip(3.4 was runnable as a script butscript/gcovris gone in the later version). FWIW the GitHub actions coverage workflow bypasses several targets in the Makefile and uses gcovr 4.2 (via pip install):node/.github/workflows/coverage-linux.yml
Line 37 in b034151
run: pip install gcovr==4.2 Alternative to using
pipis if we update the benchmark machine (where we're running the coverage builds) to Ubuntu 20.04 and installgcovrvia apt: https://packages.ubuntu.com/focal/gcovr. (Theaptpackaged versions ofgcovrin Ubuntu 16.04 is 3.2 and in Ubuntu 18.04 3.4.)Reacted by Rich Trott and Alex YangShould be addressed by changes in the Makefile and on the CI machine.
Reacted by Rich Trott- added a commit that references this issue
on Jul 11, 2021 - addedbuildIssues and PRs related to Node.js builds or CI infrastructure.Issues and PRs related to Node.js builds or CI infrastructure.coverageIssues and PRs related to Node.js code coverage support.Issues and PRs related to Node.js code coverage support.
on Jul 12, 2021 - added a commit that references this issue
on Jul 13, 2021 - added a commit that references this issue
on Sep 4, 2021

Version
master branch
Platform
n/a
Subsystem
build
What steps will reproduce the bug?
View https://coverage.nodejs.org/. See (screenshot below) that the C++ coverage broke some time around June 24 2021.
How often does it reproduce? Is there a required condition?
n/a
What is the expected behavior?
Coverage should be generated
What do you see instead?
No coverage generated
Additional information
The last commit shown where the cover worked is e0ebc6b. The commit shown where it stops working is 84d6ce9. If this is a problem in the repository (and not a build infra issue), then that means it is in one of these three commits:
84d6ce9
d65514b
bf9ce95
Of those three commits, the one that could at least plausibly could have somehow caused this is d65514b. /ping @richardlau