InvalidOperation executing command: BindProgram(0) crash on start

[euclio]

Reopening issue here for visibility. cc https://github.com/PistonDevelopers/piston-examples/issues/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]

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

[msiglreith]

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

[kvark]

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]

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

[kvark]

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

[bvssvni]

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