piston
piston copied to clipboard
Application immediately closing on SOME systems
I recently finished my first Piston project and it works fine on my main development desktop (Win10). When I open my executable on my laptop (or any other machine I've tested on), the window opens and then closes immediately.
- I thought it was a .dll issue, so I used dependency walker and found no differences.
- I tried changing the used OpenGL version all the way down to 2.1, no difference.
- Microsoft Visual C++ redists are installed.
- Graphics driver (tested on a quadro m1200 laptop) is up to date or should AT LEAST support opengl 3.2.
- Building from source works, but shows the same behaviour when run.
- RUST_BACKTRACE=1 prints nothing.
The executable quits with code 0, no errors are thrown. I've tried debugging it with Visual Studio Code and found that it randomly returns when nothing important is happening. It seems to be panicking though (seen in the stack frames).
I'm creating an issue for this as I'm pretty sure it's some internal error in Piston. Might be related to #1207 and #1202.
Edit: both the opengl and gfx backends show the same behaviour. I've switched to using piston_window now (gfx).
Reddit post: https://www.reddit.com/r/rust_gamedev/comments/7chrbf/piston_executable_not_running_on_some_windows/
Can you try another window backend?
You can change the window backend in PistonWindow by inserting a parameter:
extern crate sdl2_window;
use sdl2_window::Sdl2Window;
let mut window: PistonWindow<Sdl2Window> = ...
It crashes saying: SDL2.dll was not found. After adding that to the directory, it showed the same behaviour, BUT this time it actually printed an error message! With RUST_BACKTRACE=1 this resulted in:
an `Err` value: ""', src\libcore\result.rs:906:4
stack backtrace:
0: <unknown>
1: <unknown>
2: <unknown>
3: <unknown>
4: <unknown>
5: <unknown>
6: <unknown>
7: <unknown>
8: <unknown>
9: <unknown>
10: <unknown>
11: <unknown>
12: <unknown>
13: <unknown>
I found some information about this and it seems to be a rust bug fixed long ago (??).
After that, I tried building the application on the laptop where this issue was appearing. Apparently the SDL2.lib didn't exist inside the /toolchains/../lib folder.
" Since 0.31, this crate supports a feature named "bundled" which downloads SDL2 from source, compiles it and links it automatically. While this should work for any architecture, you will need a C compiler (like gcc, clang, or MS's own compiler) to use this feature properly. " - I do have the MS build tools installed.
For now I've copied them from my desktop. When compiling and running in debug mode, this message was printed:
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ""', src\libcore\result.rs:906:4
stack backtrace:
0: 0x7ff6c94db441 - std::sys_common::backtrace::_print
at C:\projects\rust\src\libstd\sys_common\backtrace.rs:94
1: 0x7ff6c94e147c - std::panicking::default_hook::{{closure}}
at C:\projects\rust\src\libstd\panicking.rs:380
2: 0x7ff6c94e1165 - std::panicking::default_hook
at C:\projects\rust\src\libstd\panicking.rs:397
3: 0x7ff6c94e19c5 - std::panicking::rust_panic_with_hook
at C:\projects\rust\src\libstd\panicking.rs:611
4: 0x7ff6c94e1858 - std::panicking::begin_panic<alloc::string::String>
at C:\projects\rust\src\libstd\panicking.rs:572
5: 0x7ff6c94e1731 - std::panicking::begin_panic_fmt
at C:\projects\rust\src\libstd\panicking.rs:522
6: 0x7ff6c94e169f - std::panicking::rust_begin_panic
at C:\projects\rust\src\libstd\panicking.rs:498
7: 0x7ff6c94e783e - core::panicking::panic_fmt
at C:\projects\rust\src\libcore\panicking.rs:71
8: 0x7ff6c9457daa - core::result::unwrap_failed<str*>
at C:\projects\rust\src\libcore\macros.rs:41
9: 0x7ff6c9438037 - core::result::Result<gfx_device_gl::info::Version, str*>::unwrap<gfx_device_gl::info::Version,str*>
at C:\projects\rust\src\libcore\result.rs:772
10: 0x7ff6c9491e22 - gfx_device_gl::info::Info::get
at C:\Users\20173986\.cargo\registry\src\github.com-1ecc6299db9ec823\gfx_device_gl-0.14.4\src\info.rs:193
11: 0x7ff6c94923fc - gfx_device_gl::info::get
at C:\Users\20173986\.cargo\registry\src\github.com-1ecc6299db9ec823\gfx_device_gl-0.14.4\src\info.rs:232
12: 0x7ff6c9326920 - gfx_device_gl::Device::new<closure>
at C:\Users\20173986\.cargo\registry\src\github.com-1ecc6299db9ec823\gfx_device_gl-0.14.4\src\lib.rs:251
13: 0x7ff6c9328017 - gfx_device_gl::create<closure>
at C:\Users\20173986\.cargo\registry\src\github.com-1ecc6299db9ec823\gfx_device_gl-0.14.4\src\lib.rs:173
14: 0x7ff6c933a2aa - piston_window::PistonWindow<sdl2_window::Sdl2Window>::new<sdl2_window::Sdl2Window>
at C:\Users\20173986\.cargo\registry\src\github.com-1ecc6299db9ec823\piston_window-0.73.0\src\lib.rs:183
15: 0x7ff6c93a5a0b - piston_window::{{impl}}::build_from_window_settings<sdl2_window::Sdl2Window>
at C:\Users\20173986\.cargo\registry\src\github.com-1ecc6299db9ec823\piston_window-0.73.0\src\lib.rs:152
16: 0x7ff6c9398b15 - window::WindowSettings::build<piston_window::PistonWindow<sdl2_window::Sdl2Window>>
at C:\Users\20173986\.cargo\registry\src\github.com-1ecc6299db9ec823\pistoncore-window-0.30.0\src\lib.rs:387
17: 0x7ff6c93bed37 - physics_renderer::main
at C:\Users\20173986\Documents\GitHub\Physics-Renderer\src\main.rs:37
18: 0x7ff6c94e2441 - panic_unwind::__rust_maybe_catch_panic
at C:\projects\rust\src\libpanic_unwind\lib.rs:99
19: 0x7ff6c94e1c71 - std::rt::lang_start
at C:\projects\rust\src\libstd\rt.rs:54
20: 0x7ff6c93bf51b - main
21: 0x7ff6c94edaf8 - __scrt_common_main_seh
at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:253
22: 0x7ffa52462773 - BaseThreadInitThunk
error: process didn't exit successfully: `target\debug\physics_renderer.exe` (exit code: 101)
I debugged the executable with Visual Studio Code and found out that on let shading_language = ..
(info.rs line 193) the function get_string
returns NULL and therefore crashes.
https://github.com/gfx-rs/gfx/issues/1629
@bvssvni This issue occurs when enabling anti-aliasing: window.samples( nr )
Edit: only with samples higher than 8, when the number <= 8 it just does not do anything.
Thanks for noticing.
Not 100% sure this was the problem, but
This seems to have been fixed with the latest mesa 18.*
. See https://github.com/PistonDevelopers/piston/issues/1202 for more information.