Internal compiler error on nightly: 'index out of bounds' #48923
Comments
cuviper
added
A-type-system
|
Using: CARGO_INCREMENTAL=0 cargo build instead of just cargo build, seems to resolve the problem. |
|
My program isn't correct, so I guess the problem is with some kind of diagnostics. |
|
Ok, now that I've fixed the compilation errors, the program compiles ok with CARGO_INCREMENTAL=0 . It even appears to run correctly, but it still cannot be recompiled with CARGO_INCREMENTAL=1 . It can be compiled with CARGO_INCREMENTAL=0 |
|
Ok, another lead: I was using my 'savefile' crate (which is on crates.io) with its custom-derive macro to derive an implementation of a trait called Serialize .I was also, in the crate which would not compile, using serde to derive its trait called Serialize. These are different traits. Perhaps the incremental compilation could not keep these two apart somehow? My immediate problem is solved, since I was trying out both serde and savefile, and never intended to actually use both simultaneously. |
|
I've got the same problem in a crate I'm developing. I'm also using |
|
This is tagged |
michaelwoerister
added
A-incr-comp
|
This looks indeed like a problem with incremental compilation. |
|
@jjl @avl @Ameobea since the crash seems to at least be deterministic, can anyone share the code that reproduces the crash? (minimizing it would be a huge help as well, but simply having anything would be great at this point) Barring that, you can also help by testing other nightlies to pinpoint when the problem first started occurring. (you can do |
|
triage: P-high |
|
My code is not open source. I'm willing to share the code privately, but not publically on github, if we can come up with a way to do that. |
|
I'm trying to minimize the program which causes the crash for me. I have come to where it seems to work if I remove a dependency I have upon another crate in the same workspace. Does the incremental compilation work "per crate", or is the cached intermediaries shared between crates? Is it reasonable that the bug could be triggered by code patterns in the combination of two crates where one depends on the other? |
|
Hmm, minimizing is a bit tricky. After the error has been triggered once, almost any input will yield an ICE. For instance, completely clearing lib.rs in the offending crate would still trigger ICE. However, removing dependencies from Cargo.toml would make it work again. Maybe the intermediary state/cache is thrown away when changes are detected in Cargo.toml? |
|
Ok, I'm making a lot of headway now :-) . Will have a minimal example here on github shortly. |
|
Okay, actually, this program triggers the error: #[macro_use] #[derive(Serialize)] #[derive(Serialize)] If I use the following Cargo.toml: [package] [dependencies] But, to trigger an error, you need to: 1: cargo clean Sometimes, it seems I need to run steps 3 and 4 again to provoke ICE. Possibly non-deterministic, I'm not entirely sure. |
|
Minimal example, including a convenient(?) crash.sh script: |
|
How fascinating that even It sounds to me like you are on to something about the |
|
Yeah, I thought that too! I (as a layperson) was also surprised that mentioning a crate in Cargo.toml could have an effect on compilation. Having multiple traits called Serialize is a bit suspicious, and having multiple serde versions seems like something that could the same situation to appear. Hmm, but thinking about this a bit more: The savefile_derive crate is just a custom-derive macro crate. It doesn't actually define any traits, and it doesn't depend on the savefile crate which does define Serialize. So maybe it's actually proc_macro for a trait name that is the culprit, not the actual trait name itself (although these two are of course very related). |
|
Ok, so I proceeded a bit further. If I reduce the savefile-derive crate 'lib.rs' into: #![feature(proc_macro)] #[proc_macro_derive(Savefile, attributes(versions, versions_as, default_val, default_fn))] The problem still appears. So we can eliminate the theory of multiple Serialize-traits being the culprit. Instead it seems like simply linking to a custom-derive crate at all can trigger the problem. |
|
Can you do that on the I tried repeating your experiment and am not able to reproduce it. Minimizing (that said, |
|
I've hit a very similar problem on nightly while building the Notable oddities:
gcc version: Full output |
|
@ExpHP I've now added the minimized savefile-derive crate into my github repro-project linked above. That is, to https://github.com/avl/rust_ice_48923 . The crash.sh consistently provokes the crash for my computer, even with this minimized savefile-derive crate, even if I do like: git clean -f -x -d Should be reproducible for you too, I think! Unless there's something else that differs between our systems and the issue is basically non-deterministic (affected by something like performance, file-system timestamps or whatnot :-) ) |
|
@RandomInsano I think your issue is something different. For one thing, the stack traces are not very similar, apart from the fact that both end up with an index out of range. |
|
OK, using @avl's repo I was able to reproduce something. With a compiler built with debug-assertions, building already crashes on the first try (that is, with an empty incr. comp. cache): It seems that the compiler is trying to force a query that already has a dep-node. A possible reason for this is that multiple query keys map to the same dep-node. |
|
It seems that something around Both keys have the same stable hash and the same |
|
OK, I can confirm that something is wrong with interning: The |
|
Interesting! I know serde uses a clever trick to be able to use extern types in the generated trait implementation. That trick creates a symbol named _IMPL_SERIALIZE_FOR_ < struct-name > . |
|
The // Version 1
Canonical {
variables: [] (addr=1, len=0),
value: ParamEnvAnd {
param_env: ParamEnv {
caller_bounds: [Binder(TraitPredicate(TraitRef { def_id: DefId(12/0:230 ~ serde[43ba]::ser[0]::Serializer[0]),
substs: [__S] (addr=7f0b0e434820, len=1) })),
Binder(TraitPredicate(TraitRef { def_id: DefId(2/0:886 ~ core[3da8]::marker[0]::Sized[0]),
substs: [__S] (addr=7f0b0e434820, len=1) }))] (addr=7f0b03e35410, len=2),
reveal: UserFacing,
universe: UniverseIndex(0)
},
value: std::result::Result<TraitRef { def_id: DefId(12/0:230 ~ serde[43ba]::ser[0]::Serializer[0]),
substs: [__S] (addr=7f0b0e434820, len=1) }::Ok,
TraitRef { def_id: DefId(12/0:230 ~ serde[43ba]::ser[0]::Serializer[0]),
substs: [__S] (addr=7f0b0e434820, len=1) }::Error>
}
}
// Version 2
Canonical {
variables: [] (addr=1, len=0),
value: ParamEnvAnd {
param_env: ParamEnv {
caller_bounds: [Binder(TraitPredicate(TraitRef { def_id: DefId(12/0:230 ~ serde[43ba]::ser[0]::Serializer[0]),
substs: [__S] (addr=7f0b0e434588, len=1) })),
Binder(TraitPredicate(TraitRef { def_id: DefId(2/0:886 ~ core[3da8]::marker[0]::Sized[0]),
substs: [__S] (addr=7f0b0e434588, len=1) }))] (addr=7f0b03e33c28, len=2),
reveal: UserFacing,
universe: UniverseIndex(0)
},
value: std::result::Result<TraitRef { def_id: DefId(12/0:230 ~ serde[43ba]::ser[0]::Serializer[0]),
substs: [__S] (addr=7f0b0e434588, len=1) }::Ok,
TraitRef { def_id: DefId(12/0:230 ~ serde[43ba]::ser[0]::Serializer[0]),
substs: [__S] (addr=7f0b0e434588, len=1) }::Error>
}
} |
|
@michaelwoerister hmm. That sounds bad, yes. That interning-slices code can be subtle, I guess I messed it up somehow perhaps. |
|
Although, that .. doesn't necessarily look related to canonicalization. But it seems likely to be the fault of that code. |
|
It turns out that |
|
@michaelwoerister ok let me know if I can help |
|
I think that's the problem: serde probably uses |
|
Just ran into this issue when compiling stdsimd (incrementally) on Linux with nightly. |
|
I just re-ran my test case using rustc 1.27.0-nightly (ad610be 2018-04-11) , and the problem seems to be resolved! I can't reproduce the problem with this newer rustc version. Yay for progress! :-) |
|
Thanks for confirming, @avl! |
I just got an internal compiler error. This happened after introducing a custom derive macro and using it on several structs. I'll try to narrow it down more, and will comment on this report if I make any progress.
Version
Backtrace
The text was updated successfully, but these errors were encountered: