-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
"thread 'rustc' has overflowed its stack" in glium on Linux #26467
Comments
Could someone post a stack trace with debuginfo? |
Can you also try compiling with |
It worked with |
I don't think we should use a stack so large! Could you gist a stack-trace so we can fix this worst-case? |
For some reason I tried to manually run rustc with |
@tomaka you may be able to get the most mileage out of:
|
That worked!
|
Ah well |
Does someone have an idea about what exactly is causing the problem? (I have absoutely no idea what This problem is really blocking me. Even if it gets fixed, I don't want to wait until Rust 1.3 or 1.4 is released. |
Note that this problem is still there, but I added a work-around. If someone wants to reproduce, just remove this line and compile glium. |
This works with |
Isn't MIR enabled by default as of Rust 1.12? And if so, can we close this? |
It is, and so we probably can. @tomaka has this ICE gone away? |
with rust 1.23.0 which is stable now, this compiler stack overflow crash not occured related to rust-lang/rust#26467
glium/glium#1676 suggests this bug is gone for good now |
🎉 |
Glium's master branch currently compiles just fine, but this simple pull request makes the compilation fail with:
This only happens on Linux and not Windows. Stable and nightly are both affected.
The
gl_generator
dependency is only used a build dependency to generate some Rust code that is theninclude!
ed in glium. There are only three differences between the Rust code generated by gl_generator 0.0.27 (which overflows) and the code generated by gl_generator 0.0.25 (which works). Two#[derive(Clone)]
lines added and one#[allow(raw_pointer_derive)]
.One of the two structs newly affected by
#[derive(Clone)]
is huge (around 2000 members). However the struct compiles just fine by itself. It is used as a field in glium'sContext
struct butContext
itself doesn't deriveClone
.Because of this diagnostic I fear that this is a "real" stack overflow and not just a bug leading to an infinite recursion.
The text was updated successfully, but these errors were encountered: