three-rs/three

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.

kvark commented

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.

kvark commented

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.