"Unsupported instrumentation profile format version" after nightly 2021-08-20

[ecton]

When running locally or on CI, I receive repeated error messages for each of my profraw files:

Error: 3 [ERROR] Error while executing llvm tools: Failure while running "/usr/share/rust/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-profdata" "merge" "-sparse" "/tmp/.tmpsTUZ7O/text/18373766271749578631_0_1.profraw" "/tmp/.tmpsTUZ7O/integrated-examples/bonsaidb/counter/shared/14885696362427109189_0_1.profraw" [... snipped ...] "-o" "/tmp/.tmpsTUZ7O/0/grcov.profdata"
warning: /tmp/.tmp3pHeaj/integrated-examples/bonsaidb/counter/shared/17217902266653795239_0_1.profraw: Unsupported instrumentation profile format version
[... repeated message for each of the profraw arguments above ...]

At the end, grcov bails:

error: No profiles could be merged.

Error: 3 [ERROR] A panic occurred at src/html.rs:458: attempt to divide by zero
Error: Non-zero exit code: exit status: 101
Process: [PID 15437] grcov . --binary-path ./target/debug/ -s . -t html --branch --ignore-not-existing --llvm -o coverage/ --ignore target/* --ignore xtask/* --ignore gooey/examples/*
Error: Process completed with exit code 1.

This happened between two CI runs, one was on nightly 2021-08-20 and the other was on nightly 2021-08-21. I can reproduce the issue locally, but all of my attempts to force using the old nightly version still yield the same error message. It is happening across all of my projects.

Has anyone else run into this?

Edit: This is tested against the released version of grcov, 0.8.2.

[youduda]

Same issue here. Solved it by not using the source-based approach from the readme (export RUSTFLAGS="-Zinstrument-coverage") but instead the second one:

export CARGO_INCREMENTAL=0
export RUSTFLAGS="-Zprofile -Ccodegen-units=1 -Copt-level=0 -Clink-dead-code -Coverflow-checks=off -Zpanic_abort_tests -Cpanic=abort"
export RUSTDOCFLAGS="-Cpanic=abort"
cargo test
grcov . -s . --binary-path ./target/debug/ -t html --branch --ignore-not-existing -o ./target/debug/coverage/

[ecton]

Thank you for the info! Unfortunately, I find the non-llvm based methods produce unreliable results on my codebases, so I'm hoping this can be fixed. I know I can also work around it by switching away from grcov to generating an llvm-cov report, but I prefer the output of grcov.

[youduda]

Do you use LLVM_PROFILE_FILE? I just tried it as recommended in the readme and it fixed the issue as well for the source-based approach.

rustup component add llvm-tools-preview
cargo install grcov
RUSTFLAGS='-Zinstrument-coverage' LLVM_PROFILE_FILE='coverage-%p-%m.profraw' cargo test
"$CARGO_HOME/.cargo/bin/grcov" . -s . --binary-path ./target/debug/ -t html --branch --ignore-not-existing -o coverage

[bruxisma]

Setting RUSTUP_TOOLCHAIN to nightly before executing grcov will also solve the issue 🙂

[eddyb]

You may need the env var RUSTUP_TOOLCHAIN=nightly, if that's not your default.

Otherwise, an older copy of the LLVM tools will be used, which don't support the version of rustc you're compiling with (it can only work by accident due to LLVM remaining unchanged between the two versions).

(Oops, @slurps-mad-rips was faster than me)

[ecton]

Setting RUSTUP_TOOLCHAIN to nightly before executing grcov will also solve the issue slightly_smiling_face

That was it, thank you so much. I had tracked my suspicion down to cargo-bintools but I couldn't figure out how to get grcov to pass the toolchain through.

[marco-c]

Maybe we should add this as a suggestion to the README.

[ecton]

@marco-c I was looking for a place to try to add something, but the README does have a note that I overlooked.

My issue stemmed from me manually executing cargo +nightly rather than setting the rustup default toolchain like the examples do. Until recently, executing grcov without RUSTUP_TOOLCHAIN worked (somehow, no idea why). In my mind, I assumed that since grcov was being downloaded pre-built on my CI servers, that the only thing that truly mattered was generating the coverage data, which needs nightly.

But, now that it seems like it can't work in that configuration anymore, I'm not sure that this is as important to point out. In theory, it only might affect a few other people like me who weren't just setting rustup to nightly for the CI run.

[eddyb]

worked (somehow, no idea why)

Like I said, it's a coincidence: the LLVM used by two different Rust versions happened to be identical (and/or had no changes in the profraw/profdata format).