ggez: Creating context fails with "glxSwapIntervalMESA failed"

Whenever ggez tries to make a context, it fails with UnknownError("glxSwapIntervalMESA failed"). I’ve included at the end a backtrace running the hello_world example (as of commit 40d70a79bb3f46c75b4d11bd4424c036c540a9fd).

This is running in a VM, which seems extremely likely to be the issue at some level. It’s a Ubuntu 16.04 VM running on a Windows 7 host in VMWare Workstation 12. Here’s the output of glxinfo.

I’ve tried modify the OpenGL version used, to no avail: I’ve tried 3.0, 2.1, and 1.1. Here’s the diff showing what I did in case I did it wrong:

diff --git a/examples/hello_world.rs b/examples/hello_world.rs
index 58e8e9b..c3138fd 100644
--- a/examples/hello_world.rs
+++ b/examples/hello_world.rs
@@ -62,7 +62,8 @@ impl event::EventHandler for MainState {
 // do the work of creating our MainState and running our game,
 // * then just call `game.run()` which runs the `Game` mainloop.
 pub fn main() {
-    let c = conf::Conf::new();
+    let mut c = conf::Conf::new();
+    c.backend = conf::Backend::OpenGL{major: 3, minor:0};
     let ctx = &mut Context::load_from_conf("helloworld", "ggez", c).unwrap();
 
     // We add the CARGO_MANIFEST_DIR/resources do the filesystems paths so

And here’s the backtrace:

cargo run --example hello_world
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running `target/debug/examples/hello_world`
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: UnknownError("glxSwapIntervalMESA failed")', libcore/result.rs:945:5
stack backtrace:
   0:     0x55ef91ea6c63 - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::h038efa1ead8ee277
                               at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1:     0x55ef91ea14c4 - std::sys_common::backtrace::_print::haa2469a6e6008f11
                               at libstd/sys_common/backtrace.rs:71
   2:     0x55ef91ea5c0d - std::panicking::default_hook::{{closure}}::ha5918fb5e6555fa7
                               at libstd/sys_common/backtrace.rs:59
                               at libstd/panicking.rs:206
   3:     0x55ef91ea5909 - std::panicking::default_hook::h4ddc2e74f1ee24ea
                               at libstd/panicking.rs:222
   4:     0x55ef91ea606f - std::panicking::rust_panic_with_hook::hf7d91abe57c1b397
                               at libstd/panicking.rs:400
   5:     0x55ef91ea5e92 - std::panicking::begin_panic_fmt::h83678fb4d002c950
                               at libstd/panicking.rs:347
   6:     0x55ef91ea5dc2 - rust_begin_unwind
                               at libstd/panicking.rs:323
   7:     0x55ef91eec670 - core::panicking::panic_fmt::h28698393dd7f7d54
                               at libcore/panicking.rs:71
   8:     0x55ef91986657 - core::result::unwrap_failed::hb6a6cad29b2abe59
                               at /checkout/src/libcore/macros.rs:23
   9:     0x55ef919864b6 - <core::result::Result<T, E>>::unwrap::h87e337a4feea38b9
                               at /checkout/src/libcore/result.rs:782
  10:     0x55ef91991f0d - hello_world::main::h2b713c399af204e2
                               at examples/hello_world.rs:66
  11:     0x55ef91992f01 - std::rt::lang_start::{{closure}}::h4119ece9ec322894
                               at /checkout/src/libstd/rt.rs:74
  12:     0x55ef91ea5d27 - std::panicking::try::do_call::hc331ed8d98dd7e72
                               at libstd/rt.rs:59
                               at libstd/panicking.rs:305
  13:     0x55ef91eb1f9e - __rust_maybe_catch_panic
                               at libpanic_unwind/lib.rs:102
  14:     0x55ef91ea6533 - std::rt::lang_start_internal::h2271475d0185b808
                               at libstd/panicking.rs:284
                               at libstd/panic.rs:361
                               at libstd/rt.rs:58
  15:     0x55ef91992ee1 - std::rt::lang_start::h376a47b757c20492
                               at /checkout/src/libstd/rt.rs:74
  16:     0x55ef919923fd - main
  17:     0x7fa35d9b482f - __libc_start_main
  18:     0x55ef91985858 - _start
  19:                0x0 - <unknown>

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 15 (9 by maintainers)

Commits related to this issue

Most upvoted comments

Thanks!

This does seems like a situation where you’d like to make as many errors soft as possible: it’s not like the people using ggez are going to repent and write better code if the errors are hard, since the problematic code is presumably their drivers. I’d even favor making the DPI check recoverable (of course, I’m motivated by the prospect of being able to use ggez without maintaining the world’s tiniest fork).

All that said, I’m not sure what a good way to deal with soft errors would be: maybe also return a vector of errors?