PistonDevelopers / piston_window

The official Piston convenience window wrapper for the Piston game engine
MIT License
156 stars 38 forks source link

In 0.74.0 this short program runs on debug, but on release it panics with "gl function was not loaded" #219

Closed AaronKutch closed 6 years ago

AaronKutch commented 6 years ago

This is on piston_window = "0.74.0"

extern crate piston_window;
use piston_window::*;

fn main() {
     let mut app_window: PistonWindow =
        WindowSettings::new("name", [1920, 1080])
            .build()
            .unwrap_or_else(|e| {
                panic!("Failed to build PistonWindow: {}", e)
            });
}

The only problem I have ever had with piston_window in the past is that it seemed to leak memory at several MB/s when repeatedly replacing a texture but it seems that it fixed itself several releases ago. I recently refactored some code but this simplified part has not changed.

I am very curious about is why the behavior of the debug run is different or could possibly be different from the release run.

Also, on the debug run when I add back some code to update and render a texture each frame, it seems that one core on my computer is running at 100%.

AaronKutch commented 6 years ago

Also, why is it that markdown or other related programs on websites literally never seem to work for me? It will not allow me to do a multiple line Inline code, and it does not preserve indentations among other annoyances. I am looking at the mastering markdown site but it says nothing about these things!

crazymykl commented 6 years ago

I updated your first post to fix the code highlighting, but I don't have an answer for your other issue off the top of my head.

AaronKutch commented 6 years ago

Thank you I can do it now. Also, I forgot to put the backtrace: thread 'main' panicked at 'gl function was not loaded', path_to_target...\target\release\build\gfx_gl-9226f93685e21b7b\out/gl_bindings.rs:1506:12 stack backtrace: 0: std::sys_common::backtrace::_print at C:\projects\rust\src\libstd\sys_common\backtrace.rs:91 1: std::panicking::default_hook::{{closure}} at C:\projects\rust\src\libstd\panicking.rs:383 2: std::panicking::default_hook at C:\projects\rust\src\libstd\panicking.rs:397 3: std::panicking::rust_panic_with_hook at C:\projects\rust\src\libstd\panicking.rs:577 4: ::fmt 5: gfx_gl::FnPtr::new 6: ::fmt 7: gfx_device_gl::info::get 8: ImageBase 9: panic_unwind::__rust_maybe_catch_panic at C:\projects\rust\src\libpanic_unwind\lib.rs:101 10: std::rt::lang_start at C:\projects\rust\src\libstd\rt.rs:51 11: scrt_common_main_seh at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:253 12: BaseThreadInitThunk

timClicks commented 6 years ago

This is affecting me too on 0.75. I believe it relates to a buggy glium 0.10 release. See also https://github.com/glium/glium/issues/1648

AaronKutch commented 6 years ago

It seems that all my problems were fixed in 0.76. Thank you devs