Panicking on Rust 1.50.0
dtmelt opened this issue · 4 comments
Building and running the following minimum example panics on Rust 1.50.0:
fn main() {
let mut win = three::Window::new("test");
let cam = win.factory.perspective_camera(60.0, 1.0..1000.0);
cam.look_at([5.0, 5.0, 5.0], [0.0, 0.0, 0.0], None);
while win.update() {
win.render(&cam)
}
}
The backtrace is:
thread 'main' panicked at 'attempted to leave type `platform::platform::x11::util::input::PointerState` uninitialized, which is invalid', /home/dtmelt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/mem/mod.rs:659:9
stack backtrace:
0: rust_begin_unwind
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/std/src/panicking.rs:493:5
1: core::panicking::panic_fmt
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/core/src/panicking.rs:92:14
2: core::panicking::panic
at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/core/src/panicking.rs:50:5
3: core::mem::uninitialized
at /home/dtmelt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/mem/mod.rs:659:9
4: winit::platform::platform::x11::util::input::<impl winit::platform::platform::x11::xdisplay::XConnection>::query_pointer
at /home/dtmelt/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.18.1/src/platform/linux/x11/util/input.rs:94:51
5: winit::platform::platform::x11::EventsLoop::process_event
at /home/dtmelt/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.18.1/src/platform/linux/x11/mod.rs:884:45
6: winit::platform::platform::x11::EventsLoop::poll_events
at /home/dtmelt/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.18.1/src/platform/linux/x11/mod.rs:203:13
7: winit::platform::platform::EventsLoop::poll_events
at /home/dtmelt/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.18.1/src/platform/linux/mod.rs:505:44
8: winit::EventsLoop::poll_events
at /home/dtmelt/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.18.1/src/lib.rs:273:9
9: three::window::Window::update
at /home/dtmelt/.cargo/registry/src/github.com-1ecc6299db9ec823/three-0.4.0/src/window.rs:198:9
10: rsboids::main
at ./src/main.rs:25:11
11: core::ops::function::FnOnce::call_once
at /home/dtmelt/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
I believe this is happening due to a problem in the version of winit that three currently depends on.
The dependency gfx_window_glutin="0.28.0" has dependency glutin="0.19.0", which depends on an outdated version of winit="0.18.1".
The current version of gfx_window_glutin="0.31.0" has dependency glutin="0.21.2" and uses a slightly more recent version of winit="0.19.3" but I am not sure if this version (not the most recent) fixes the issue or not.
Indeed, looks like we'd need to update winit here.
The old gfx crates are all long been deprecated though.
Are you currently using three
and would like to continue using it in the future?
I suppose we would accept a PR that bumps glutin/winit versions to gfx's pre-ll
branch and publish it.
Hi, I actually came across three while trying to begin this tutorial:
https://blog.bitsacm.in/a-fistful-of-boids/
Do you know of a crate with similar abstraction levels to three that works with whichever crates replaced gfx?
If not I would be willing to take a swing at writing that PR.
That's a great tutorial indeed! I wish we had something like this on modern tooling...
You could take a look at Bevy engine - https://bevyengine.org/
Otherwise, please file PRs to https://github.com/gfx-rs/gfx/tree/pre-ll (pre-ll branch), and we'll get it published.
Thanks kvark. I will give Bevy a shot and circle back to those PRs if I am not successful.