Skip to content
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

InvalidOperation executing command: BindProgram(0) crash on start #1664

Open
euclio opened this issue Dec 5, 2017 · 6 comments
Open

InvalidOperation executing command: BindProgram(0) crash on start #1664

euclio opened this issue Dec 5, 2017 · 6 comments

Comments

@euclio
Copy link

euclio commented Dec 5, 2017

Reopening issue here for visibility. cc PistonDevelopers/piston-examples#408

Machine: MacBook Pro 15 inch, 2017
OS: MacOS 10.12
Graphics: Radeon Pro 555 2048MB
Intel HD Graphics 630 1536MB

Attempting to run the multi_window example in piston-examples in debug mode crashes on my machine. The windows are displayed briefly, followed by a crash. Release mode works as expected.

$ RUST_BACKTRACE=1 cargo run --bin multi_window
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running `target/debug/multi_window`
thread 'main' panicked at 'Error InvalidOperation executing command: BindProgram(0)', /Users/anrussell/.cargo/registry/src/github.com-1ecc6299db9ec823/gfx_device_gl-0.14.5/src/lib.rs:777:12
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:69
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:58
             at src/libstd/panicking.rs:381
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:397
   4: std::panicking::begin_panic
             at src/libstd/panicking.rs:577
   5: std::panicking::begin_panic
             at src/libstd/panicking.rs:538
   6: std::panicking::try::do_call
             at src/libstd/panicking.rs:522
   7: gfx_device_gl::Device::process
             at /Users/anrussell/.cargo/registry/src/github.com-1ecc6299db9ec823/gfx_device_gl-0.14.5/src/lib.rs:777
   8: gfx_device_gl::Device::unbind_target
             at /Users/anrussell/.cargo/registry/src/github.com-1ecc6299db9ec823/gfx_device_gl-0.14.5/src/lib.rs:406
   9: gfx_device_gl::Device::no_fence_submit
             at /Users/anrussell/.cargo/registry/src/github.com-1ecc6299db9ec823/gfx_device_gl-0.14.5/src/lib.rs:782
  10: gfx_device_gl::Device::track_mapped_gpu_access
             at /Users/anrussell/.cargo/registry/src/github.com-1ecc6299db9ec823/gfx_device_gl-0.14.5/src/lib.rs:906
  11: <gfx::encoder::Encoder<R, C>>::flush_no_reset
             at /Users/anrussell/.cargo/registry/src/github.com-1ecc6299db9ec823/gfx-0.16.1/src/encoder.rs:194
  12: <gfx::encoder::Encoder<R, C>>::flush
             at /Users/anrussell/.cargo/registry/src/github.com-1ecc6299db9ec823/gfx-0.16.1/src/encoder.rs:185
  13: <piston_window::PistonWindow<W>>::draw_2d
             at /Users/anrussell/.cargo/registry/src/github.com-1ecc6299db9ec823/piston_window-0.73.0/src/lib.rs:227
  14: multi_window::main
             at src/multi_window.rs:21
  15: panic_unwind::dwarf::eh::read_encoded_pointer
             at src/libpanic_unwind/lib.rs:99
  16: <std::rand::reader::ReaderRng<R> as rand::Rng>::fill_bytes
             at src/libstd/panicking.rs:459
             at src/libstd/panic.rs:361
             at src/libstd/rt.rs:59
  17: multi_window::main::{{closure}}
@euclio
Copy link
Author

euclio commented Jan 11, 2018

FWIW I'm still seeing this after upgrading to 10.13.2 High Sierra.

@msiglreith
Copy link
Contributor

Could be some context creation issue imo as BindProgram(0) is probably the first GL call.

@kvark
Copy link
Member

kvark commented Jan 12, 2018

These examples use gfx_device_gl = "0.14.0" where the latest version is 0.20.0, which is quite ahead (edit: I was thinking of gfx_window_glutin. GL backend is now at 0.15.0). Please try running our examples (from pre-ll branch) and see if those work.

@euclio
Copy link
Author

euclio commented Jan 12, 2018

The examples seem to work correctly. So, is this a bug in piston_window?

@kvark
Copy link
Member

kvark commented Jan 13, 2018

@euclio no. More likely, it's a bug that has been fixed, so piston_window needs to update it's dependencies.

@bvssvni
Copy link
Contributor

bvssvni commented Jul 31, 2020

I still see this bug on OSX 10.11.6 with Gfx 0.18.1.

@kvark kvark reopened this Jul 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants