Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LLVM coverage regression in nightly-2022-01-15 #93054

Closed
ecton opened this issue Jan 19, 2022 · 5 comments · Fixed by #93144
Closed

LLVM coverage regression in nightly-2022-01-15 #93054

ecton opened this issue Jan 19, 2022 · 5 comments · Fixed by #93144
Assignees
Labels
A-code-coverage Area: Source-based code coverage (-Cinstrument-coverage) C-bug Category: This is a bug. regression-untriaged Untriaged performance or correctness regression. requires-nightly This issue requires a nightly compiler in some way. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@ecton
Copy link
Contributor

ecton commented Jan 19, 2022

Between nightly versions 2022-01-14 and 2022-01-15, grcov 0.8.2 lost track of 82% of the coverage of BonsaiDb when using the LLVM coverage option (-Zinstrument-coverage).

Other projects of mine continue to have code coverage correctly measured. I'm not where to start narrowing this down, as I'm not getting any errors or warnings printed.

Here are the steps to get good code coverage reports out of 2022-01-14:

git clone https://github.com/khonsulabs/bonsaidb.git
cd bonsaidb

rustup toolchain install nightly-2022-01-14 --component llvm-tools-preview
LLVM_PROFILE_FILE=%m.profraw RUSTFLAGS="-Zinstrument-coverage" cargo +nightly-2022-01-14 test --workspace --all-features --all-targets
RUST_TOOLCHAIN=nightly-2022-01-14 grcov . --binary-path ./target/debug/ -s . -t html --branch --ignore-not-existing --llvm -o coverage/ --ignore "target/*" --ignore "xtask/*"

If you look at the report in the coverage folder, the html report will show >80% coverage. Now, test with the next nightly:

# Clean up files
find . -name "*.profraw" -exec rm \{\} \;
rm -rf **/*.bonsaidb

rustup toolchain install nightly-2022-01-15 --component llvm-tools-preview
cargo clean
LLVM_PROFILE_FILE=%m.profraw RUSTFLAGS="-Zinstrument-coverage" cargo +nightly-2022-01-15 test --workspace --all-features --all-targets
RUST_TOOLCHAIN=nightly-2022-01-15 grcov . --binary-path ./target/debug/ -s . -t html --branch --ignore-not-existing --llvm -o coverage/ --ignore "target/*" --ignore "xtask/*"

If you look at the report again, the html report now shows < 1% coverage.

The quantity of profraw files are the same, and the sizes of the files are more or less equivalent. I'm not quite sure where to start narrowing this down since it's a unique issue to this project of mine -- but the only unique part I'm aware of is its size 😅.

For now I'll pin our CI to the last working nightly. Thank you in advance for any suggestions or help!

@ecton ecton added C-bug Category: This is a bug. regression-untriaged Untriaged performance or correctness regression. labels Jan 19, 2022
@rustbot rustbot added the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Jan 19, 2022
ecton added a commit to khonsulabs/khonsu-tools that referenced this issue Jan 19, 2022
Reported rust-lang/rust#93054

Technically this isn't affecting all of our projects, but it seemed
easier to just pin it here and unpin once fixed. Having it in this one
location will make it easier if nightly ever breaks again for any
raeason.
@fpoli
Copy link
Contributor

fpoli commented Jan 19, 2022

We noticed the same when upgrading rustc in our project from nightly-2021-12-15 (December) to nightly-2022-01-17. Code coverage measured with -Zinstrument-coverage and grcov inexplicably dropped from 76% to 28%. Some crates that are clearly running don't show up at all in the reports.

tikv/tikv#11875 (comment) suggests that this is probably caused by #92142

@mati865
Copy link
Contributor

mati865 commented Jan 19, 2022

^ taiki-e/cargo-llvm-cov#128 says nightly-2022-01-15 is also affected.

@Urgau
Copy link
Member

Urgau commented Jan 19, 2022

cc @wesleywiser @richkadel

@rustbot label +requires-nightly +A-code-coverage

@rustbot rustbot added A-code-coverage Area: Source-based code coverage (-Cinstrument-coverage) requires-nightly This issue requires a nightly compiler in some way. labels Jan 19, 2022
@wesleywiser
Copy link
Member

wesleywiser commented Jan 19, 2022

Thanks for the report! I've tried reproducing locally and I'm able to see the same behavior. Running the LLVM tools directly, I see this when trying to process coverage data for the various binaries:

error: target/debug/deps/bonsaidb_keystorage_s3-438dd0d4a1f4a274: Failed to load coverage: Truncated coverage data
error: Could not load coverage information
error: target/debug/deps/bonsaidb_local-72f1e7d9d3d420d1: Failed to load coverage: Truncated coverage data
error: Could not load coverage information
error: target/debug/deps/bonsaidb_core-e06ccf75f46726e6: Failed to load coverage: Truncated coverage data
error: Could not load coverage information
error: target/debug/deps/bonsaidb_macros-7da7619a94109db7: Failed to load coverage: Truncated coverage data
error: Could not load coverage information
error: target/debug/deps/bonsaidb-9d5002ec7642a5fa: Failed to load coverage: Truncated coverage data
error: Could not load coverage information
error: target/debug/deps/bonsaidb-09fb12b0ad5856f2: Failed to load coverage: Truncated coverage data
error: Could not load coverage information
error: target/debug/deps/bonsaidb_server-41b846b92bb6128a: Failed to load coverage: Truncated coverage data
error: Could not load coverage information
error: target/debug/deps/bonsaidb-c4775d66b4dcbbc0: Failed to load coverage: Truncated coverage data
error: Could not load coverage information

which seems to be the same issue as was reported in a comment on #79645. I'm continuing to investigate ...

@wesleywiser
Copy link
Member

The minimal repro seems to be

enum Never { }

impl Never {
    fn foo(self) {
        match self { }
    }
}

fn main() { }

I think I'll have a fix for this within the next few days.

@wesleywiser wesleywiser self-assigned this Jan 20, 2022
@apiraino apiraino added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jan 20, 2022
kantai added a commit to stacks-network/stacks-core that referenced this issue Jan 21, 2022
lpenz added a commit to lpenz/ghaction-rust-coverage that referenced this issue Jan 24, 2022
We are pinning it to a version where coverage works.
Ref: rust-lang/rust#93054
lpenz added a commit to lpenz/ghaction-rust-coverage that referenced this issue Jan 24, 2022
RUSTC_BOOTSTRAP=1 doesn't work so well anymore in stable, so we had to
migrate to nightly - which required us to install the toolchain in an
image that already has one. If we install rust manually in a
debian-slim, we save ~500MB.

We are also pinning nightly to a version where coverage works.
Ref: rust-lang/rust#93054
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Jan 25, 2022
…ov2, r=tmandry

Work around missing code coverage data causing llvm-cov failures

If we do not add code coverage instrumentation to the `Body` of a
function, then when we go to generate the function record for it, we
won't write any data and this later causes llvm-cov to fail when
processing data for the entire coverage report.

I've identified two main cases where we do not currently add code
coverage instrumentation to the `Body` of a function:

  1. If the function has a single `BasicBlock` and it ends with a
     `TerminatorKind::Unreachable`.

  2. If the function is created using a proc macro of some kind.

For case 1, this is typically not important as this most often occurs as
a result of function definitions that take or return uninhabited
types. These kinds of functions, by definition, cannot even be called so
they logically should not be counted in code coverage statistics.

For case 2, I haven't looked into this very much but I've noticed while
testing this patch that (other than functions which are covered by case
1) the skipped function coverage debug message is occasionally triggered
in large crate graphs by functions generated from a proc macro. This may
have something to do with weird spans being generated by the proc macro
but this is just a guess.

I think it's reasonable to land this change since currently, we fail to
generate *any* results from llvm-cov when a function has no coverage
instrumentation applied to it. With this change, we get coverage data
for all functions other than the two cases discussed above.

Fixes rust-lang#93054 which occurs because of uncallable functions which shouldn't
have code coverage anyway.

I will open an issue for missing code coverage of proc macro generated
functions and leave a link here once I have a more minimal repro.

r? `@tmandry`
cc `@richkadel`
@bors bors closed this as completed in 8dddc86 Jan 25, 2022
@camelid camelid removed the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Jan 25, 2022
gnomesysadmins pushed a commit to GNOME/librsvg that referenced this issue Feb 18, 2022
I'm interested in a newer nightly to see if that fixes the coverage
job - #841

See rust-lang/rust#93054
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-code-coverage Area: Source-based code coverage (-Cinstrument-coverage) C-bug Category: This is a bug. regression-untriaged Untriaged performance or correctness regression. requires-nightly This issue requires a nightly compiler in some way. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants