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

Spurious "found two different crates with name alloc" errors in PR builder #64389

Closed
Centril opened this issue Sep 11, 2019 · 9 comments
Closed
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. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.

Comments

@Centril
Copy link
Contributor

Centril commented Sep 11, 2019

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

Some relatively unscientific digging for where we create SVHs dug up this bit of code -- that sort_unstable looks rather suspicious, as it's presumably possible for two crates with different hashes to end up in a different order, and then when we go on to hash it it'll lead to problems down the line if the sort resulted in a different ordering then we'd expect.

To be clear, thinking some more about this, I think it's presumably fine for this to be an unstable sort since an unstable sort should still have stable output, it just might be different than input order, AIUI -- what's not fine is that we're introducing non-determinism by not sorting by hash.

cc @michaelwoerister who I believe is the original author of this bit of code in 8129c53

cc @Zoxc @aturon -- this is a potentially interesting case for wg-parallel-rustc to examine, as it's a case where we need to be careful about ordering in a subtle way -- the output of a query is assumed to be ordering-stable across compilations, otherwise this svh computation won't work well I believe, though not certain

@Mark-Simulacrum
Copy link
Member

Another note is that this is likely to prove rather hard to track down as to what caused this as we've seen relatively few of these errors - the PR description lists one case, and anecdotal data suggests maybe around 6 or so errors that we've noted like this. Interestingly, all were specifically in these liballoc doctests which explicitly have an extern crate alloc;; maybe that points to the bug (Cc @petrochenkov, in case this is somehow resolver related). I suspect that means we have something like two extern crate allocs in these tests due to rustdoc auto-insertion, but haven't verified.

I personally suspect this is sort of due to #63470 which likely causes us to keep around more artifacts than previously and perhaps one of those is contaminating the path whereas it didn't before; to be clear, this exposed the bug perhaps but almost certainly didn't cause it.

@ehuss
Copy link
Contributor

ehuss commented Sep 12, 2019

Has this happened before #63827?

@Mark-Simulacrum
Copy link
Member

I believe so, but not completely confident. It occurs really rarely, so it's hard to be certain unfortunately.

@michaelwoerister
Copy link
Member

Copying my comment from discord:
The list being sorted there should never contain duplicate entries. (crate-name, crate-disambiguator) must uniquely identify a crate, otherwise there'll be logic errors all over the place.
One could add an assertion after sorting that this list does indeed not contain duplicates. If it does that points to a bug in a different place.

Cargo usually takes care of correctly setting crate disambiguators but if this occurs in a setup that is not driven by Cargo, then that might be the source of the bug. Two versions of the same crate must always be compiled with differing crate disambiguators. The disambiguators are how we implement supporting multiple versions of the same crate.

Another note: The following line should make sure that we sort lexicographically (as opposed to some kind of pointer value) here:
8129c53#diff-5c91206f29170d97620d0f4bce664722R139

If that is not the case for some reason, the sort order would indeed be undeterministic.

@Centril
Copy link
Contributor Author

Centril commented Nov 7, 2019

I haven't seen this reproduced for a long time so I'll close it for now.

@Centril Centril closed this as completed Nov 7, 2019
@mati865
Copy link
Contributor

mati865 commented Nov 7, 2019

There was similar error recently but with bitflags when building rustdoc: #66108

@Centril Centril reopened this Nov 7, 2019
@Enselic
Copy link
Member

Enselic commented Dec 9, 2023

Triage: Has anyone here seen this error in recent years?

@ehuss
Copy link
Contributor

ehuss commented Dec 9, 2023

GitHub search shows the most recent this particular message was in #67281, 4 years ago.

The error message has since changed. I'm going to close, since I don't think this is a direct issue anymore. Here are my notes:

The error appeared when compiling alloc doctests, while loading the alloc library via extern crate alloc;.

error[E0523]: found two different crates with name `alloc` that are not distinguished by differing `-C metadata`. This will result in symbol conflicts between the two.

There was a verification step in creader.rs which would check if two crates have the same stable crate ID, but different SVH, and it would raise that error.

#100928 migrated to use the new diagnostics.

#100599 removed the particular message and replaced it with a bug!:

bug!(
    "Previously returned E0523 here. \
     See https://github.com/rust-lang/rust/pull/100599 for additional discussion.\
     root.name() = {}.",
    root.name()
);

Looks like the authors couldn't find a way to create a test for it, and thought that maybe it was an unreachable section.
However, jyn happened to run into it after bug! was added.

Shortly afterwards, the bug! and SVH check was simply removed in #109213 which refactored things to eagerly verify collisions (updated in #111461). Now, if there are two crates with the same stable crate ID, the errors are now:

  • If collision with local crate:
    SymbolConflictsCurrent
    E0519 the current crate is indistinguishable from one of its dependencies: it has the same crate-name {$crate_name} and was compiled with the same -C metadata arguments. This will result in symbol conflicts between the two.
  • If it knows the name of the other:
    StableCrateIdCollision
    found crates ({$crate_name0} and {$crate_name1}) with colliding StableCrateId values.
  • If it doesn't know the name of the other:
    NotFound
    CannotFindCrate
    can't find crate

Searching for those error messages doesn't pull up anything recent.

@ehuss ehuss closed this as not planned Won't fix, can't repro, duplicate, stale Dec 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in 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. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

6 participants