Skip to content

Spurious assertion in rustc_codegen_ssa/src/back/write.rs #87083

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

Closed
michaelwoerister opened this issue Jul 12, 2021 · 2 comments
Closed

Spurious assertion in rustc_codegen_ssa/src/back/write.rs #87083

michaelwoerister opened this issue Jul 12, 2021 · 2 comments
Labels
A-spurious Area: Spurious failures in builds (spuriously == for no apparent reason) C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@michaelwoerister
Copy link
Member

There seems to be a race condition that sometimes triggers this assertion in CI builds:

assert_eq!(main_thread_worker_state, MainThreadWorkerState::Codegenning);

See #86965 (comment) for an example.

Let's start collecting instances of this issue here.

@michaelwoerister michaelwoerister added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. C-bug Category: This is a bug. labels Jul 12, 2021
@Mark-Simulacrum Mark-Simulacrum added the A-spurious Area: Spurious failures in builds (spuriously == for no apparent reason) label Jul 12, 2021
@lqd
Copy link
Member

lqd commented Jul 13, 2021

When I looked at this last time, it seemed:

There are other such assertions when other messages are received, maybe the state machine could contain other unexpected state transitions with respect to the main thread worker state ? (For example -- and I don't know if it's possible for this to happen -- while the main thread worker is LLVMing, receiving a Message::Token() would transition the main thread worker to idle, which could then trigger similar assertions if Message::Codegen{Done,Aborted,Complete} messages are then received)

@Enselic
Copy link
Member

Enselic commented Dec 20, 2023

Triage: The assert was removed in b00d0fa so let's close this as obsolete.

@Enselic Enselic closed this as not planned Won't fix, can't repro, duplicate, stale Dec 20, 2023
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-spurious Area: Spurious failures in builds (spuriously == for no apparent reason) C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants