panic on startup on OS X Yosemite when loading BindBuffersBase
Closed this issue · 7 comments
thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', /private/tmp/rust20150626-13301-uiklsd/rustc-1.1.0/src/libcore/option.rs:362
stack backtrace:
1: 0x102f05e1f - sys::backtrace::write::h4d34c75aaa44ebb3c2r
2: 0x102f09584 - panicking::on_panic::hacede89293da7355Lgw
3: 0x102efcc35 - rt::unwind::begin_unwind_inner::h5f5b5041038f2bdbuYv
4: 0x102efcfdc - rt::unwind::begin_unwind_fmt::hf422928da74ad1a4AXv
5: 0x102f08e3c - rust_begin_unwind
6: 0x102f27405 - panicking::panic_fmt::h0ece6850f56551b8f3B
7: 0x102f26b64 - panicking::panic::h8e0828861061ce45M1B
8: 0x102ed6278 - option::Option<T>::unwrap::h7340955155689965868
9: 0x102e56e58 - gpu::opengl::Renderer::new::closure.12112
10: 0x102e58e9e - load_with::closure.12217
11: 0x102e58cf4 - metaloadfn::h7713124497418738431
12: 0x102e58c3d - BindBuffersBase::load_with::h18178951034605948107
13: 0x102e526a3 - load_with::h2438887132135737744
14: 0x102e517d0 - gpu::opengl::Renderer::new::h7c8e68b4fea3e7c0pnd
15: 0x102ee78eb - main::h3e82e9ed9324e15bN2e
16: 0x102f0a6a8 - rust_try_inner
17: 0x102f0a695 - rust_try
18: 0x102f09d90 - rt::lang_start::h204325cf25bd6ae3gbw
19: 0x102eeb5ee - main
I'm not sure why BindBuffersBase would have an issue?
I'm going to try refactoring to a newer sdl2 and see if that fixes it up
I wish I wasn't lazy and put proper error handling in my OpenGL code (but OpenGL error handling is so painful...). I also wish rust's Option wouldn't put the error in libcore instead of the calling code.
From this backtrace it seems that the error is in sdl2::video::gl_get_proc_address(s).unwrap() in src/gpu/opengl/mod.rs
I've just pushed a commit improving the error diagnostics in this part of the code, hopefully it should give us some clues about what goes wrong.
Similar issue here.
thread '<main>' panicked at 'Can't get proc address for glBindTextureUnit', src/gpu/opengl/mod.rs:69
stack backtrace:
1: 0x7f46479f3bb0 - sys::backtrace::tracing::imp::write::h0f988057ddbbdebbKlt
2: 0x7f46479f5f45 - panicking::log_panic::_<closure>::closure.39234
3: 0x7f46479f5991 - panicking::log_panic::h7d832f79be8aa8d4Wlx
4: 0x7f46479e98e3 - sys_common::unwind::begin_unwind_inner::hb994f7ba157b2162bds
5: 0x7f46479e9a38 - sys_common::unwind::begin_unwind_fmt::h649a0735a6cdbdf4hcs
6: 0x7f464797096e - gpu::opengl::_<impl>::new::_<closure>::closure.19026
at /home/yann/code/rust/rustation/<std macros>:8
7: 0x7f4647973323 - gl::load_with::_<closure>::closure.19211
at target/debug/build/gl-9653698dd50d604e/out/bindings.rs:22495
8: 0x7f46479731f2 - metaloadfn::metaloadfn::h9965409650451829332
at target/debug/build/gl-9653698dd50d604e/out/bindings.rs:13
9: 0x7f4647973190 - BindTextureUnit::load_with::load_with::h1925743892630598600
at target/debug/build/gl-9653698dd50d604e/out/bindings.rs:9053
10: 0x7f464796c5e8 - load_with::load_with::h16510004567656881384
at target/debug/build/gl-9653698dd50d604e/out/bindings.rs:22495
11: 0x7f464796b5c1 - gpu::opengl::_<impl>::new::hb7d90dc26a803d4frye
at src/gpu/opengl/mod.rs:67
12: 0x7f46479d7841 - main::h981e8e82b125442aKFi
at src/main.rs:82
13: 0x7f46479f56d4 - sys_common::unwind::try::try_fn::h11739288761102791194
14: 0x7f46479f30e8 - __rust_try
15: 0x7f46479f536f - rt::lang_start::hdbc2e8a9fd66e7ff4ix
16: 0x7f46479db599 - main
17: 0x7f464707eb44 - __libc_start_main
18: 0x7f4647945978 - <unknown>
19: 0x0 - <unknown>
This is strange because glBindTextureUnit is part of OpenGL 4 (https://www.opengl.org/sdk/docs/man/html/glBindTextureUnit.xhtml), but code in gpu/opengl/mod.rs asks for version 3?
sdl2::video::gl_set_attribute(GLAttr::GLContextMajorVersion, 3);
I changed opengl/mod.rs to:
67 gl::load_with(|s|
68 match sdl2::video::gl_get_proc_address(s) {
69 None => {
70 //panic!("Can't get proc address for {}", s),
71 println!("Can't get proc address for {}", s);
72 0 as *const c_void
73 }
74 Some(a) => a as *const c_void,
75 });
Output is then:
Can't get proc address for glBindTextureUnit
Can't get proc address for glBlitNamedFramebuffer
Can't get proc address for glCheckNamedFramebufferStatus
Can't get proc address for glClearNamedBufferData
Can't get proc address for glClearNamedBufferSubData
Can't get proc address for glClearNamedFramebufferfi
Can't get proc address for glClearNamedFramebufferfv
Can't get proc address for glClearNamedFramebufferiv
Can't get proc address for glClearNamedFramebufferuiv
Can't get proc address for glClipControl
Can't get proc address for glCompressedTextureSubImage1D
Can't get proc address for glCompressedTextureSubImage2D
Can't get proc address for glCompressedTextureSubImage3D
Can't get proc address for glCopyNamedBufferSubData
Can't get proc address for glCopyTextureSubImage1D
Can't get proc address for glCopyTextureSubImage2D
Can't get proc address for glCopyTextureSubImage3D
Can't get proc address for glCreateBuffers
Can't get proc address for glCreateFramebuffers
Can't get proc address for glCreateProgramPipelines
Can't get proc address for glCreateQueries
Can't get proc address for glCreateRenderbuffers
...
I searched for some of them, and it seems that these are recent (OpenGL > 4) extensions:
https://www.opengl.org/sdk/docs/man/html/glBindTextureUnit.xhtml
https://www.opengl.org/sdk/docs/man/html/glCreateBuffers.xhtml
https://www.opengl.org/sdk/docs/man/html/glCreateRenderbuffers.xhtml
Also, my driver is supposed to support OpenGL 4:
glxinfo | grep "OpenGL version"
OpenGL version string: 4.4.0 NVIDIA 340.65
Can you tweak opengl/mod.rs and take a look at your output?
Thank you for taking the time to test that, does the emulator work (as in, boot the BIOS since it doesn't do a whole lot more at that point) if you replace the panic! with a println! ?
I asked @tomaka for advice and he told me that OS X only supports OpenGL 3.2 and not 3.3 so it gives us a 4.1 context here which explains the errors (I hope I understood that correctly). I don't think I use any of those missing functions so hopefully that shouldn't be an issue.
I guess the right way to do this would be for me to list all the required OpenGL functions and only report an error when one of those can't be loaded.
Alternatively I'll try to request OpenGL 3.1 or 3.2 instead of 3.3, maybe it'll solve those issues on hardware/OS that don't support later versions. I thought 3.3 was conservative enough, apparently I was wrong...
I should have precised that, without the panic!, the emulator indeed works (logo is a bit scrambled, but otherwise OK).
Okay, I'll make the error non-fatal then. If a required function is missing it'll panic later on. Thank you for the feedback.