Compilation appears to loop indefinitely #89195
Assignees
Labels
C-bug
Category: This is a bug.
E-needs-mcve
Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example
I-hang
Issue: The compiler never terminates, due to infinite loops, deadlock, livelock, etc.
P-high
High priority
regression-from-stable-to-stable
Performance or correctness regression from one stable version to another.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Milestone
Comments
|
You can attach gdb to the running process and then |
|
Do the prebuilt nightlies include enough symbols to get useful backtraces? |
|
Yes. Another and perhaps more helpful option is to create a reduced testcase. http://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-patterns/ and https://github.com/jethrogb/rust-reduce Bisecting is another option. https://github.com/rust-lang/cargo-bisect-rustc/blob/master/TUTORIAL.md |
|
|
searched nightlies: from nightly-2021-09-04 to nightly-2021-09-22 bisected with cargo-bisect-rustc v0.6.0Host triple: x86_64-unknown-linux-gnu cargo bisect-rustc --start=2021-09-04 --end=2021-09-22 --script=./build-binaries.sh --prompt |
|
Reducing this to a testcase isn't going to happen unless there's an automated process for that. |
the8472
added
I-hang
rustbot
added
the
I-prioritize
|
cc @Aaron1011 |
apiraino
added
T-compiler
|
We're seeing a very similar issue building the Running @olix0r ran builds with
We found that the regressed build spent a majority of its time in the Unfortunately, we also don't have a minimized reproduction, but we do, at least, have an open-source project that can be checked out and tested against (and should be easy to build with |
|
I can also provide the complete output from |
You can use tools like However, something else worries me. Your backtrace shows @khuey can you try |
|
@wesleywiser Do you happen to know whether |
This is borderline offtopic, but it would be handy to have some contractors sign NDAs for situations like this. |
I think we could probably support that as long as we're not recording query keys. Query keys aren't serialized until the very end and can take a relatively significant amount of time to complete. |
|
@hawkw What commit of linkerd2-proxy are you building? |
|
@Aaron1011 I've been trying to do mostly-automated reduction, just to learn the tools, and I am preparing a longer comment, but just to help you out, I was able to repro by compiling with I didn't pick a specific commit, but happen to be at linkerd/linkerd2-proxy@93a1f29. |
I was also building on linkerd/linkerd2-proxy@93a1f29. And, I can confirm @eddyb's observation that it appears to be the |
|
I started the following automated reduction, using a rustup install nightly-2021-09-17
rustup install nightly-2021-09-18
# Get the script.
curl -sSO https://gist.githubusercontent.com/eddyb/b2e2cc5121675da718977383100c5d39/raw/192b00ba2e30e0038b3aef57959edf36009f12f9/is_89195_repro.sh
chmod +x is_89195_repro.sh
# Get the relevant source and set the env var used by the script.
git clone https://github.com/linkerd/linkerd2-proxy
export REDUCE_CRATE=linkerd2-proxy/linkerd/app/inbound
# Run the script on its own once to build deps.
./is_89195_repro.sh $REDUCE_CRATE/src/lib.rs
# Install `rust-reduce` (from my fork that supports Rust 2018) and run it.
cargo install --git https://github.com/eddyb/rust-reduce --branch rustfmt-2018
rust-reduce ./is_89195_repro.sh $REDUCE_CRATE/src/lib.rs
# Over an hour later, we have an output (you can stop it sooner though).
# Make a copy just in case `creduce` does something weird.
cp $REDUCE_CRATE/src/lib.rs checkpoint-1-rust-reduce.rs
# Don't want `creduce` to get its hands on the remaining modules'
# original files, after `rust-reduce` inlined them into `lib.rs`,
# so keep only `lib.rs` (from the copy we just made).
rm $REDUCE_CRATE/src/**.rs
cp checkpoint-1-rust-reduce.rs $REDUCE_CRATE/src/lib.rs
# Finally, run `creduce`, which will (hopefully) do most of the work.
# The `--n 1` flag is important - the script is not parallel-safe!
creduce --not-c --n 1 --timing ./is_89195_repro.sh $REDUCE_CRATE/src/lib.rsNow that I got it to the EDIT1: accounted for #89195 (comment). I've heard concerns over |
I can confirm that |
Have you compared it to a prior version? I'm seeing: vs So, while it's not nearly as severe as the build issue, it still looks like a sizable regression to me. |
Ah, good point. I can confirm that result; on 2021-09-18, I get while on 2021-09-16, it only takes 12 seconds: |
|
Running with self-profile on 2021-09-16 as a baseline: measureme summarize outputRunning 2021-09-18 next, but expect that to take much longer :) |
measureme summarize output: |
|
Those Which makes me wonder how accurate #89195 (comment) is. Could there be two (or more) regressions here? But also, I suspect there may be some confusion going on in the thread.
The assumption is that only the crate being listed, was compiled. But that may not be the case. Alternatively, this is what I prefer to do (partly because it's way more automatable):
|
camelid
added
regression-from-stable-to-beta
|
Shouldn't the label say regression from stable to stable @camelid? The regression is also present in 1.56 |
|
I’ve heard from several who’s projects using axum compile significantly slower on 1.56:
@paolobarbolini is right that this is a regression from stable to stable. Anything we can do to help with this issue? |
|
I don't believe the changeset that we identified as causing this regression is present in 1.56. The regression in #89601 doesn't point to the same range as this. I don't think that bug is a duplicate of this. |
The bisections above (e.g., #89195 (comment)) showed that the regression occurred in #88945, which landed in 1.57.0 according to its automatically-added milestone. Based on #89195 (comment), it seems that there is also a separate, similar regression that landed in 1.56.0. |
|
I think I ran into this issue too, I reduced it to this (probably can be reduced further...): (rustc does not return for me on stable&nightly -- could also be something independent/or can't be detected due to the cyclic dependency) |
|
The above example seems indeed related to recursive types, as the following is enough to trigger the problem: pub trait Dispatch {
type WriteOperation;
}
pub struct Log<'a, T>(&'a Log<'a, <T as Dispatch>::WriteOperation>);(but that seems to reproduce on older versions, as old as 1.31, and thus unrelated to the OP) |
With Adding that constraint still leads to an error: Adding the suggested I guess the issue is with polymorphic type recursion? It's interesting that using |
|
I'm also got hit by this error today. It seems to be passing the both lifetime and T::AssociatedType recursively makes this problem. use std::marker::PhantomData;
trait MyTrait {
type AnotherMyTrait: MyTrait;
}
// rustc infinitely loops
struct Item<'foo, T: MyTrait> {
phantom: PhantomData<Item<'foo, T::AnotherMyTrait>>,
_just_for_remove_unused_error: PhantomData<&'foo T>,
}Does anyone know if this is supposed to be an error code actually, or just the compiler is not supporting yet? |
|
Assigning priority as discussed in the Zulip thread of the Prioritization Working Group. @rustbot label -I-prioritize +P-high |
rustbot
added
P-high
pnkfelix
added
regression-from-stable-to-stable
|
I didn't do much here other than review. The real thanks should go to @Aaron1011 and the others who have done related work. |
|
I don't observe this on 1.59.0. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have a crate that appears to iloop when being built with nightly 308dffd 2021-09-22. This crate is not open source.
What can I provide to diagnose this?
The text was updated successfully, but these errors were encountered: