Compiler runs out of memory #53746
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-compilemem
Issue: Problems and improvements with respect to memory usage during compilation.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
|
The linked commit fails to compile without any excessive memory use for me (<200MB). I'm on |
|
Using the same nightly on the same architecture the compiler continues to use quite a lot of memory. So here are more detailed steps to reproduce:
If there are more informations needed please ask. |
|
So I've run |
|
Indeed I can reproduce now. The |
|
I went in with GDB and took a number of representative stack traces while watching the memory increase. The final backtrace is for the OOM. Backtraces (as GDB writes them)Same backtraces but without the "from" lines so that you can read them without going crosseyedTwo key things sticks out to me:
|
|
@weiznich Perhaps you can help minimize this? Removing (For now I wouldn't worry too much about minimizing |
|
|
Thanks! I asked simply because the rustc debugging cycle is faster when proc macros aren't needed (and I wasn't sure what to grep for in the case of This bug is probably out of my league, but I feel invested in it now, and I'll be poking around this area of rustc in my free time at least until somebody who knows what they're doing shows up. :P |
|
I've digged in somewhat deeper. The problem seems to be this function. Removing ~half of the |
|
Ooh, wow! Does Edit: ah, I see it has |
|
Just a note: I tried replacing the calls to |
|
I've managed to solve this by changing some of the code. The problem was the calculation of an associated type on a hlist with 24 elements. Here is the corresponding change. Hopefully that helps fixing the underlying issue. |
jonas-schievink
added
T-compiler
Enselic
added
the
E-needs-mcve
|
A smaller example. It takes 20 seconds to fail to compile and uses. With more "meat" it uses much more memory. pub trait MultiVisitor<'a> {
type Scalar;
fn with<V>(self) -> MultiVisitorCons<V, Self>
where
Self: Sized;
}
pub struct MultiVisitorNil<S>(S);
impl<'a, S> MultiVisitor<'a> for MultiVisitorNil<S> {
type Scalar = ();
fn with<V>(self) -> MultiVisitorCons<V, Self> {
todo!()
}
}
struct MultiVisitorCons<A, B>(A, B);
impl<'a, A, B> MultiVisitor<'a> for MultiVisitorCons<A, B>
where
B: MultiVisitor<'a, Scalar = ()>,
{
type Scalar = ();
fn with<V>(self) -> MultiVisitorCons<V, Self> {
todo!()
}
}
fn visit_all_rules() {
let mv = MultiVisitorNil::<()>(())
.with()
.with()
.with()
.with()
.with()
.with()
.with()
.with()
.with()
.with()
.with()
.with()
.with()
.with()
.with()
.with()
.with()
.with();
} |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've trying to change a crate to be more generic, so I've started to add some generics to some types and then continued to add them where the compiler suggests (more or less).
That worked pretty fine till the crate stopped "compiling" because it is running out of memory (with a peak of ~30GB) and gets killed by the OS.
The code the reproduce this is unfortunately quite big because I don't know what exactly caused this.
There are not that much generics in there, compared to for example diesel, so I don't think the generics itself are the problem. More likely this is the result of a half finished transformation of everything to the new generic form.
This happens with the latest rustc nightly.
The text was updated successfully, but these errors were encountered: