Skip to content

Profraw files are not produced when using instrument-coverage on freebsd #94616

New issue

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

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

Already on GitHub? # to your account

Open
elinorbgr opened this issue Mar 4, 2022 · 5 comments
Open
Labels
A-code-coverage Area: Source-based code coverage (-Cinstrument-coverage) C-bug Category: This is a bug. O-freebsd Operating system: FreeBSD

Comments

@elinorbgr
Copy link
Contributor

Running the following command on the calloop repo on a FreeBSD environment:

env LLVM_PROFILE_FILE="calloop-%p-%m.profraw" RUSTFLAGS="-Cinstrument-coverage" cargo +nightly test --all-features

No .profraw file is produced with the latest nightly (which now causes our CI script to fail).

Meta

The files were correctly produced with rustc 1.60.0-nightly (88fb06a1f 2022-02-05), but are no longer produced on rustc 1.60.0-nightly (30b3f35c4 2022-02-17) nor rustc 1.61.0-nightly (10913c000 2022-03-03). This fails on both FreeBSD 13.0 and FreeBSD 12.1 (according to our CI).

Running the command on Linux using rustc 1.61.0-nightly (10913c000 2022-03-03) works as expected, producing the .profraw files.

@elinorbgr elinorbgr added the C-bug Category: This is a bug. label Mar 4, 2022
@nagisa
Copy link
Member

nagisa commented Mar 4, 2022

For this to be really actionable, it would be great if you could reduce the regression range further. E.g. using https://github.com/rust-lang/cargo-bisect-rustc.

cc #79121

@nagisa nagisa added O-freebsd Operating system: FreeBSD B-unstable Blocker: Implemented in the nightly compiler and unstable. A-code-coverage Area: Source-based code coverage (-Cinstrument-coverage) and removed B-unstable Blocker: Implemented in the nightly compiler and unstable. labels Mar 4, 2022
@elinorbgr
Copy link
Contributor Author

elinorbgr commented Mar 4, 2022

As a first range reduction, I can say that rustc 1.60.0-nightly (30b3f35c4 2022-02-17) is actually the first nightly to have the problem, the previous one rustc 1.60.0-nightly (75d9a0ae2 2022-02-16) works fine.

Looking at the associated commit range, an obvious suspect is 30b3f35, which merges #93577, upgrading to LLVM 14. I'll see if I manage to confirm this using cargo-bisect-rustc

@elinorbgr
Copy link
Contributor Author

I confirm that the issue was introduced by 30b3f35.

elinorbgr added a commit to Smithay/calloop that referenced this issue Mar 5, 2022
asomers added a commit to bfffs/bfffs that referenced this issue Jun 4, 2022
Recent Rust toolchains cannot be used for coverage checking on FreeBSD.
Lock the toolchain version in the coverage check script as a workaround.

rust-lang/rust#94616
@asomers
Copy link
Contributor

asomers commented Aug 5, 2023

@elinorbgr I can no longer reproduce this bug using Rust 1.73.0-nightly and a recent build of FreeBSD 14.

@elinorbgr
Copy link
Contributor Author

Indeed, it seems to work now! Thanks for the ping!

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-code-coverage Area: Source-based code coverage (-Cinstrument-coverage) C-bug Category: This is a bug. O-freebsd Operating system: FreeBSD
Projects
None yet
Development

No branches or pull requests

3 participants