Skip to content

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

Open

Description

@elinorbgr

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.

Activity

  1. nagisa commented on Mar 4, 2022

    @nagisa
    Member

    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

  2. added
    O-freebsdOperating system: FreeBSD
    B-unstableBlocker: Implemented in the nightly compiler and unstable.
    A-code-coverageArea: Source-based code coverage (-Cinstrument-coverage)
    and removed
    B-unstableBlocker: Implemented in the nightly compiler and unstable.
    on Mar 4, 2022
  3. elinorbgr commented on Mar 4, 2022

    @elinorbgr
    ContributorAuthor

    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

  4. elinorbgr commented on Mar 4, 2022

    @elinorbgr
    ContributorAuthor

    I confirm that the issue was introduced by 30b3f35.

  5. added a commit that references this issue on Mar 5, 2022
  6. asomers commented on Aug 5, 2023

    @asomers
    Contributor

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

  7. elinorbgr commented on Aug 26, 2023

    @elinorbgr
    ContributorAuthor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-code-coverageArea: Source-based code coverage (-Cinstrument-coverage)C-bugCategory: This is a bug.O-freebsdOperating system: FreeBSD

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions