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

hello_triangle_c panics while unwrapping power preference #102

Closed
cshenton opened this issue Mar 11, 2019 · 9 comments
Closed

hello_triangle_c panics while unwrapping power preference #102

cshenton opened this issue Mar 11, 2019 · 9 comments
Labels
type: bug Something isn't working

Comments

@cshenton
Copy link

Running hello_triangle_c causes the following error in on the rust side:

thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:345:21
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:70
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:58
             at src/libstd/panicking.rs:200
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:215
   4: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:478
   5: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:385
   6: rust_begin_unwind
             at src/libstd/panicking.rs:312
   7: core::panicking::panic_fmt
             at src/libcore/panicking.rs:85
   8: core::panicking::panic
             at src/libcore/panicking.rs:49
   9: <core::option::Option<T>>::unwrap
             at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858/src/libcore/macros.rs:10
  10: wgpu_native::instance::instance_get_adapter
             at wgpu-native/src/instance.rs:152
  11: wgpu_native::instance::instance_get_adapter
             at wgpu-native/src/instance.rs:161
  12: main
fatal runtime error: failed to initiate panic, error 5
Abort trap: 6

Steps to repro on macOS

git clone https://github.com/gfx-rs/wgpu.git
cd wgpu
cargo build 
# We now have target/debug/libwgpu_native.dylib

cd examples/hello_triangle_c
cmake .
make hello_triangle

export RUST_BACKTRACE=1
./hello_triangle_c

glfw 3.2.1
cmake 3.13.4
make 3.81
rust 1.33
macos 10.13.6
xcode 10.1

@grovesNL
Copy link
Collaborator

I can't confirm right now but I believe we don't assume any backend by default, so you'll need to specify cargo build --features metal or cargo build --features gfx-backend-metal depending on which crate you build.

We could probably provide an error when no backend has been selected.

@kvark kvark added the type: bug Something isn't working label Mar 11, 2019
@cshenton
Copy link
Author

I suspected it was something to do with selecting a backend. To clarify my understanding, is it correct to say that I've compiled wgpu with no backend, and then the C code calls correctly into the rust library which was compiled incorrectly?

@cshenton
Copy link
Author

I've just cloned a fresh copy of the repo and built with cargo build --features metal using the same repro steps above and am getting the same error.

@cshenton
Copy link
Author

In addition, running the following from the root of a fresh copy of the repo:

make lib-native
cd examples/hello_triangle_c/
cmake .
make hello_triangle
./hello_triangle

Results in a Segmentation fault: 11

@cshenton
Copy link
Author

I also don't see gfx-backend-metal in the features section of wgpu-native's Cargo.toml, which could explain why the conditional compilation of the metal backend is working for the rust example but not the C one.

@grovesNL
Copy link
Collaborator

grovesNL commented Mar 11, 2019

To clarify my understanding, is it correct to say that I've compiled wgpu with no backend, and then the C code calls correctly into the rust library which was compiled incorrectly?

That's right, the library needs to be compiled with a particular backend specified (most functions will fail when they hit an unimplemented somewhere).

The Makefile is probably out of date because it existed before we switched to cmake for the C example.

I also don't see gfx-backend-metal in the features section of wgpu-native's Cargo.toml

I don't think this should be required because it's an optional crate (i.e. --features gfx-backend-metal should work).

You should be able to run the command (including all of the cds) we just added to Travis: https://github.com/gfx-rs/wgpu/blob/master/.travis.yml#L47 I also forgot to mention the local flag when building wgpu-native directly.

Edit: We also have a Gitter to chat if it's easier to discuss there.

@cshenton
Copy link
Author

Brilliant! The command from travis builds a binary that works on my machine.

Thanks so much for being so responsive on this. Now I can start experimenting against the C API.

@kvark
Copy link
Member

kvark commented Mar 11, 2019

@cshenton don't hesitate to visit us on gitter or elsewhere! We'd be happy to showcase your screenshots in the gallery.

@mokpi
Copy link

mokpi commented Nov 18, 2023

The link provided above by grovesNL no longer works, but I believe it refers to this line found here in 508b724.

  - if [[ $TRAVIS_OS_NAME == "osx" ]]; then (brew update && brew upgrade cmake && brew install glfw3 && cd wgpu-native && cargo build --features=local,gfx-backend-metal && cd ../examples/hello_triangle_c && mkdir build && cd build && cmake .. && make); fi

However, it seems such a long ago answer is no longer applicable if one faces the same issue in 2023 or onwards, at least in my own experience that's the case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants