Gfx: InvalidFrameBufferOperation upon closing window on Mac OS X

Created on 23 Jan 2018  路  1Comment  路  Source: gfx-rs/gfx

I don't know if this is a Mac OS X specific issue, but when I ran the mipmap example and closed the window by clicking the "X" button in the top of the window, the example crashed with:

     Running `target/debug/examples/mipmap`
thread 'main' panicked at 'Error InvalidFramebufferOperation executing command: Clear(Some(Float([0.1, 0.2, 0.3, 1.0])), None, None)', src/backend/gl/src/lib.rs:818:13
note: Run with `RUST_BACKTRACE=1` for a backtrace.
Avg frame time: 34.15555555555556 ms

Here's some information about the Mac I am using:

Metadata

Platform: x86_64-apple-darwin
rustc --version         Mon Jan 22 20:05:06 2018
         rustc 1.25.0-nightly (15a1e2844 2018-01-20)

Based on Apple's documentation, my OpenGL version is 4.1 and my OpenCL version is 1.2.

Stack backtrace

stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:68
             at libstd/sys_common/backtrace.rs:57
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:380
   3: std::panicking::default_hook
             at libstd/panicking.rs:396
   4: std::panicking::begin_panic
             at libstd/panicking.rs:576
   5: std::panicking::begin_panic
             at libstd/panicking.rs:537
   6: std::panicking::try::do_call
             at libstd/panicking.rs:521
   7: gfx_device_gl::Device::process
             at src/backend/gl/src/lib.rs:818
   8: gfx_device_gl::Device::no_fence_submit
             at src/backend/gl/src/lib.rs:825
   9: gfx_device_gl::Device::track_mapped_gpu_access
             at src/backend/gl/src/lib.rs:947
  10: <gfx::encoder::Encoder<R, C>>::flush_no_reset
             at ./src/render/src/encoder.rs:197
  11: <gfx::encoder::Encoder<R, C>>::flush
             at ./src/render/src/encoder.rs:188
  12: <gfx_app::Wrap<R, C, A> as gfx_app::ApplicationBase<R, C>>::render
             at ./src/lib.rs:459
  13: gfx_app::launch_gl3::{{closure}}
             at ./src/lib.rs:181
  14: winit::platform::platform::events_loop::EventsLoop::run_forever::{{closure}}
             at /Users/sam/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.10.0/src/platform/macos/events_loop.rs:226
  15: winit::platform::platform::events_loop::Modifiers::new
             at /Users/sam/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.10.0/src/platform/macos/events_loop.rs:149
  16: winit::platform::platform::events_loop::EventsLoop::run_forever
             at /Users/sam/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.10.0/src/platform/macos/events_loop.rs:257
  17: winit::EventsLoop::run_forever
             at /Users/sam/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.10.0/src/lib.rs:231
  18: gfx_app::launch_gl3
             at ./src/lib.rs:151
  19: gfx_app::Application::launch_default
             at ./src/lib.rs:420
  20: gfx_app::Application::launch_simple
             at ./src/lib.rs:416
  21: mipmap::main
             at examples/mipmap/main.rs:138
  22: std::rt::lang_start::{{closure}}
             at /Users/travis/build/rust-lang/rust/src/libstd/rt.rs:74
  23: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:479
  24: panic_unwind::dwarf::eh::read_encoded_pointer
             at libpanic_unwind/lib.rs:102
  25: std::sys_common::bytestring::debug_fmt_bytestring
             at libstd/panicking.rs:458
             at libstd/panic.rs:358
             at libstd/rt.rs:58
  26: std::rt::lang_start
             at /Users/travis/build/rust-lang/rust/src/libstd/rt.rs:74
  27: <mipmap::Vertex as gfx::pso::buffer::Structure<gfx_core::format::Format>>::query
pre-ll OpenGL OSX ready for work bug medium

Most helpful comment

This is actually specific to glutin; it doesn't happen when using SDL or GLFW.

It's fixed in tomaka/winit#476. Prior to that, Closed on macOS (and Windows, along with X11 as of 0.11.3) meant that the window was already closed, which made it very easy to exist in an invalid state.

>All comments

This is actually specific to glutin; it doesn't happen when using SDL or GLFW.

It's fixed in tomaka/winit#476. Prior to that, Closed on macOS (and Windows, along with X11 as of 0.11.3) meant that the window was already closed, which made it very easy to exist in an invalid state.

Was this page helpful?
0 / 5 - 0 ratings