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

rustc hangs and takes increasing amounts of memory when compiling json crate as dependency #89647

Closed
adrian17 opened this issue Oct 7, 2021 · 7 comments
Assignees
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-bug Category: This is a bug. 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

@adrian17
Copy link

adrian17 commented Oct 7, 2021

Reproduction:

  • use nightly rustc (with wasm target installed)
  • clone https:/ruffle-rs/ruffle
  • cd web
  • cargo build --release --verbose -j1 --target=wasm32-unknown-unknown

Result: under a minute into the build, the compiler hangs when compiling the json dependency, taking increasingly more memory; after 40s it spiked to 1GB, then 2GB and more. The json crate is tiny with no dependencies of its own, normally it should take <5s to build.

Weirdly, I cannot reproduce it when building the json crate's repo on its own, but I may be missing some build configuration difference.

Reproduced on builds starting with nightly-2021-09-26 (rustc 1.57.0-nightly (addb4da68 2021-09-25)), it works fine on earlier build. Also someone else managed to reproduce this on latest nightly too.

@adrian17 adrian17 added the C-bug Category: This is a bug. label Oct 7, 2021
@saethlin
Copy link
Member

saethlin commented Oct 8, 2021

This might be the same bug as in #89524, I see the same sort of behavior. I need to be compiling toml as a dependency, not just a version of toml that produces the very long build time. I also see some memory growth initially, but it stops at ~0.5 GB. I think the biggest difference is that in #89524 memory growth eventually stops and LLVM does its best to optimize a tremendous amount of IR.

Also interesting that we're both seeing this related to parsing crates. I wonder if there's something about them that makes whatever pattern is present more likely.

@adrian17
Copy link
Author

adrian17 commented Nov 18, 2021

Do you think this set of issues could be considered a NewPM (I'm assuming it's NewPM-related) blocker?
I just verified that this reproduces on GH Actions and kills the build: https:/adrian17/ruffle/runs/4253768752?check_suite_focus=true#step:8:291

@apiraino
Copy link
Contributor

apiraino commented Jan 6, 2022

@adrian17 I'm not 100% sure but I'm thinking if a smaller reproducible would help correlating this to #89524 and - by extension - to the new LLVM 13 pass manager. Do some of the debugging done in #89524 also apply to this issue?

@adrian17
Copy link
Author

adrian17 commented Feb 25, 2022

Looks like this regression is now on stable 1.59.
This makes it impossible to build dependencies for our project locally and on CI, so we'll have to lock version to 1.58 for the time being.

@apiraino sorry, I missed the notification back then; but I didn't investigate this further. (I also don't know how to pass --debug-pass=Details)

@apiraino
Copy link
Contributor

Summarizing here (for SEO purposes) from the linked issues the mitigating flags that make the issue disappear: setting the release build profile opt-level != 3 (mentioned here)

 [profile.release]
 panic = "abort"
+opt-level = 0       # or 2

or disabling the new LLVM pass manager altogether:

$ RUSTFLAGS="-Z new-llvm-pass-manager=no" \
    cargo +nightly build --release --verbose -j1 --target=wasm32-unknown-unknown

@Mark-Simulacrum Mark-Simulacrum added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. regression-from-stable-to-stable Performance or correctness regression from one stable version to another. labels Feb 26, 2022
@rustbot rustbot added the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Feb 26, 2022
@Mark-Simulacrum Mark-Simulacrum added this to the 1.59.0 milestone Feb 26, 2022
@apiraino apiraino added I-compiler-nominated Nominated for discussion during a compiler team meeting. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 3, 2022
@nikic
Copy link
Contributor

nikic commented Mar 7, 2022

It looks like ruffle switched away from json in the meantime, so this also needs a git checkout fa459f7547e0d13c97394108ed0051956a92a1da now. It also looks like this reproduced with stable but not nightly -- probably the LLVM 14 upgrade perturbed things enough that it doesn't happen anymore. (The root issue still exists though.)

@nikic nikic self-assigned this Mar 9, 2022
@nikic
Copy link
Contributor

nikic commented Mar 10, 2022

This is supposed to be fixed by #94764, but as mentioned above, I already couldn't reproduce this on nightly before that, so I can't verify whether this specific instance of the problem has been addressed.

If someone still sees hangs with the new pass manager, please let me know.

@nikic nikic closed this as completed Mar 10, 2022
@apiraino apiraino removed I-prioritize Issue: Indicates that prioritization has been requested for this issue. I-compiler-nominated Nominated for discussion during a compiler team meeting. labels Apr 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-bug Category: This is a bug. 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.
Projects
None yet
Development

No branches or pull requests

6 participants