out of memory #124901
Labels
C-bug
Category: This is a bug.
I-compilemem
Issue: Problems and improvements with respect to memory usage during compilation.
I-crash
Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.
P-medium
Medium priority
regression-from-stable-to-stable
Performance or correctness regression from one stable version to another.
Milestone
Comments
matthiaskrgr
added
I-crash
rustbot
added
the
needs-triage
|
|
This gave an error back in 1.76: |
matthiaskrgr
added
the
regression-from-stable-to-stable
rustbot
added
the
I-prioritize
|
Infinite recursion from Since |
|
Bisection points to fb4bca0 (but unsure if directly related) cc @reitermarkus @dtolnay bisected with cargo-bisect-rustc v0.6.8Host triple: x86_64-unknown-linux-gnu cargo bisect-rustc --without-cargo --preserve --start 1.76.0 --end 1.77.0 --timeout 2 --script test.sh |
|
WG-prioritization assigning priority (Zulip discussion). @rustbot label -I-prioritize +P-medium |
rustbot
added
P-medium
|
This frame is suspicious, since the code around it is already trying to avoid infinite recursion: rust/compiler/rustc_query_impl/src/plumbing.rs Lines 328 to 334 in cf77474 cc @Zoxc who added that I think maybe it should set the reduced state here, e.g. this seems to work: diff --git a/compiler/rustc_query_impl/src/plumbing.rs b/compiler/rustc_query_impl/src/plumbing.rs
index a7696b1fbaff..7a9a1fafc579 100644
--- a/compiler/rustc_query_impl/src/plumbing.rs
+++ b/compiler/rustc_query_impl/src/plumbing.rs
@@ -330,7 +330,7 @@ pub(crate) fn create_query_frame<
// so exit to avoid infinite recursion.
None
} else {
- Some(key.default_span(tcx))
+ Some(ty::print::with_reduced_queries!(key.default_span(tcx)))
};
let def_id = key.key_as_def_id();
let def_kind = if kind == dep_graph::dep_kinds::def_kind || reduce_queries { |
|
I don't immediately spot why there's a cycle from the limited backtrace or why the check for |
|
Here's a full backtrace. I was breaking on each Click to expand
|
saethlin
removed
the
needs-triage
|
There's a cycle with Somehow this leads to a situation with Backtrace: |
TaKO8Ki
added a commit
to TaKO8Ki/rust
that referenced
this issue
Mar 26, 2025
…handler, r=oli-obk Avoiding calling queries when collecting active queries This PR changes active query collection to no longer call queries. Instead the fields needing queries have their computation delayed to when an cycle error is emitted or when printing the query backtrace in a panic. This is done by splitting the fields in `QueryStackFrame` needing queries into a new `QueryStackFrameExtra` type. When collecting queries `QueryStackFrame` will contain a closure that can create `QueryStackFrameExtra`, which does make use of queries. Calling `lift` on a `QueryStackFrame` or `CycleError` will convert it to a variant containing `QueryStackFrameExtra` using those closures. This also only calls queries needed to collect information on a cycle errors, instead of information on all active queries. Calling queries when collecting active queries is a bit odd. Calling queries should not be done in the deadlock handler at all. This avoids the out of memory scenario in rust-lang#124901.
Zalathar
added a commit
to Zalathar/rust
that referenced
this issue
Mar 27, 2025
…handler, r=oli-obk Avoiding calling queries when collecting active queries This PR changes active query collection to no longer call queries. Instead the fields needing queries have their computation delayed to when an cycle error is emitted or when printing the query backtrace in a panic. This is done by splitting the fields in `QueryStackFrame` needing queries into a new `QueryStackFrameExtra` type. When collecting queries `QueryStackFrame` will contain a closure that can create `QueryStackFrameExtra`, which does make use of queries. Calling `lift` on a `QueryStackFrame` or `CycleError` will convert it to a variant containing `QueryStackFrameExtra` using those closures. This also only calls queries needed to collect information on a cycle errors, instead of information on all active queries. Calling queries when collecting active queries is a bit odd. Calling queries should not be done in the deadlock handler at all. This avoids the out of memory scenario in rust-lang#124901.
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Mar 27, 2025
Rollup merge of rust-lang#138672 - Zoxc:deferred-queries-in-deadlock-handler, r=oli-obk Avoiding calling queries when collecting active queries This PR changes active query collection to no longer call queries. Instead the fields needing queries have their computation delayed to when an cycle error is emitted or when printing the query backtrace in a panic. This is done by splitting the fields in `QueryStackFrame` needing queries into a new `QueryStackFrameExtra` type. When collecting queries `QueryStackFrame` will contain a closure that can create `QueryStackFrameExtra`, which does make use of queries. Calling `lift` on a `QueryStackFrame` or `CycleError` will convert it to a variant containing `QueryStackFrameExtra` using those closures. This also only calls queries needed to collect information on a cycle errors, instead of information on all active queries. Calling queries when collecting active queries is a bit odd. Calling queries should not be done in the deadlock handler at all. This avoids the out of memory scenario in rust-lang#124901.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Unfortunately there is no kind of error or warning given by rustc, it just OOMs right away :/
I tried this code:
I expected to see this happen: explanation
Instead, this happened: explanation
Meta
rustc --version --verbose:The text was updated successfully, but these errors were encountered: