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

coverage: Avoid ICE when coverage_cx is unexpectedly unavailable #132395

Merged
merged 1 commit into from
Oct 31, 2024

Conversation

Zalathar
Copy link
Contributor

In #132124, coverage_cx() was changed to panic if the context was unavailable, under the assumption that it would always be available whenever coverage instrumentation is enabled.

However, there have been reports of this change causing ICEs in polars CI.

I don't yet understand why this is happening, but for now it seems wisest to revert that part of the change, restoring the two early returns that had been replaced with panics.

@Zalathar Zalathar added the A-code-coverage Area: Source-based code coverage (-Cinstrument-coverage) label Oct 31, 2024
@rustbot
Copy link
Collaborator

rustbot commented Oct 31, 2024

r? @cjgillot

rustbot has assigned @cjgillot.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Oct 31, 2024
@Zalathar
Copy link
Contributor Author

cc @orlp

@Zalathar Zalathar marked this pull request as ready for review October 31, 2024 10:23
Copy link
Member

@jieyouxu jieyouxu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks

@jieyouxu
Copy link
Member

r? jieyouxu
@bors r+ rollup p=1 (fixes an ICE encountered by polars so affects real-world code)

@bors
Copy link
Contributor

bors commented Oct 31, 2024

📌 Commit 8dddd1a has been approved by jieyouxu

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 31, 2024
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Oct 31, 2024
coverage: Avoid ICE when `coverage_cx` is unexpectedly unavailable

In rust-lang#132124, `coverage_cx()` was changed to panic if the context was unavailable, under the assumption that it would always be available whenever coverage instrumentation is enabled.

However, there have been reports of this change causing ICEs in `polars` CI.

I don't yet understand why this is happening, but for now it seems wisest to revert that part of the change, restoring the two early returns that had been replaced with panics.
@Zalathar
Copy link
Contributor Author

Zalathar commented Oct 31, 2024

I think this occurs when instrumented code is MIR-inlined into a crate that is being built without coverage.

(This is an uncommon configuration, because cargo makes it hard to do mixed-coverage builds, and usually people want their leaf crates to be instrumented. But it can happen when enabling coverage via RUSTFLAGS, and then running doctests, because the doctests ignore the normal RUSTFLAGS and get built without coverage, then inline code from the main crates that has coverage instrumentation.)

bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 31, 2024
…iaskrgr

Rollup of 5 pull requests

Successful merges:

 - rust-lang#130693 (Add `minicore` test auxiliary and support `//@ add-core-stubs` directive in ui/assembly/codegen tests)
 - rust-lang#132316 (CI: use free runners for 3 fast windows jobs)
 - rust-lang#132354 (Add `lp64e` RISC-V ABI)
 - rust-lang#132395 (coverage: Avoid ICE when `coverage_cx` is unexpectedly unavailable)
 - rust-lang#132396 (CI: use free runners for x86_64-gnu-tools and x86_64-rust-for-linux)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit bfc956e into rust-lang:master Oct 31, 2024
6 checks passed
@rustbot rustbot added this to the 1.84.0 milestone Oct 31, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Oct 31, 2024
Rollup merge of rust-lang#132395 - Zalathar:coverage-cx-ice, r=jieyouxu

coverage: Avoid ICE when `coverage_cx` is unexpectedly unavailable

In rust-lang#132124, `coverage_cx()` was changed to panic if the context was unavailable, under the assumption that it would always be available whenever coverage instrumentation is enabled.

However, there have been reports of this change causing ICEs in `polars` CI.

I don't yet understand why this is happening, but for now it seems wisest to revert that part of the change, restoring the two early returns that had been replaced with panics.
@Zalathar Zalathar deleted the coverage-cx-ice branch October 31, 2024 22:22
@Zalathar
Copy link
Contributor Author

After thinking some more, it’s not just MIR inlining. Any time code from crate A (coverage on) appears in crate B (coverage off) for any reason (e.g. #[inline], generics), we end up with either orphaned coverage statements, or code that “should” have instrumentation but doesn’t.

I don’t think there’s a good solution for this in the foreseeable future, but we at least want to not ICE when it happens.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Nov 1, 2024
…r=jieyouxu

coverage: Regression test for inlining into an uninstrumented crate

Regression test for rust-lang#132395, after I was able to figure out a simple way to reproduce it. See also rust-lang#132436.

In addition to confirming that there is no ICE, this test also demonstrates that the affected code is undercounted, because executing the inlined copy doesn't increment coverage counters.
jieyouxu added a commit to jieyouxu/rust that referenced this pull request Nov 1, 2024
…r=jieyouxu

coverage: Regression test for inlining into an uninstrumented crate

Regression test for rust-lang#132395, after I was able to figure out a simple way to reproduce it. See also rust-lang#132436.

In addition to confirming that there is no ICE, this test also demonstrates that the affected code is undercounted, because executing the inlined copy doesn't increment coverage counters.
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Nov 2, 2024
…r=jieyouxu

coverage: Regression test for inlining into an uninstrumented crate

Regression test for rust-lang#132395, after I was able to figure out a simple way to reproduce it. See also rust-lang#132436.

In addition to confirming that there is no ICE, this test also demonstrates that the affected code is undercounted, because executing the inlined copy doesn't increment coverage counters.
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Nov 2, 2024
…r=jieyouxu

coverage: Regression test for inlining into an uninstrumented crate

Regression test for rust-lang#132395, after I was able to figure out a simple way to reproduce it. See also rust-lang#132436.

In addition to confirming that there is no ICE, this test also demonstrates that the affected code is undercounted, because executing the inlined copy doesn't increment coverage counters.
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Nov 2, 2024
…r=jieyouxu

coverage: Regression test for inlining into an uninstrumented crate

Regression test for rust-lang#132395, after I was able to figure out a simple way to reproduce it. See also rust-lang#132436.

In addition to confirming that there is no ICE, this test also demonstrates that the affected code is undercounted, because executing the inlined copy doesn't increment coverage counters.
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Nov 3, 2024
…r=jieyouxu

coverage: Regression test for inlining into an uninstrumented crate

Regression test for rust-lang#132395, after I was able to figure out a simple way to reproduce it. See also rust-lang#132436.

In addition to confirming that there is no ICE, this test also demonstrates that the affected code is undercounted, because executing the inlined copy doesn't increment coverage counters.
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Nov 3, 2024
…r=jieyouxu

coverage: Regression test for inlining into an uninstrumented crate

Regression test for rust-lang#132395, after I was able to figure out a simple way to reproduce it. See also rust-lang#132436.

In addition to confirming that there is no ICE, this test also demonstrates that the affected code is undercounted, because executing the inlined copy doesn't increment coverage counters.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Nov 3, 2024
…r=jieyouxu

coverage: Regression test for inlining into an uninstrumented crate

Regression test for rust-lang#132395, after I was able to figure out a simple way to reproduce it. See also rust-lang#132436.

In addition to confirming that there is no ICE, this test also demonstrates that the affected code is undercounted, because executing the inlined copy doesn't increment coverage counters.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Nov 3, 2024
…r=jieyouxu

coverage: Regression test for inlining into an uninstrumented crate

Regression test for rust-lang#132395, after I was able to figure out a simple way to reproduce it. See also rust-lang#132436.

In addition to confirming that there is no ICE, this test also demonstrates that the affected code is undercounted, because executing the inlined copy doesn't increment coverage counters.
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Nov 3, 2024
Rollup merge of rust-lang#132437 - Zalathar:inline-mixed-regression, r=jieyouxu

coverage: Regression test for inlining into an uninstrumented crate

Regression test for rust-lang#132395, after I was able to figure out a simple way to reproduce it. See also rust-lang#132436.

In addition to confirming that there is no ICE, this test also demonstrates that the affected code is undercounted, because executing the inlined copy doesn't increment coverage counters.
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) S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants