Describe how you arrived at the problem. If you can, consider providing a code snippet or link.
I've setup a simple bevy project, with a barebones applications through default plugins and run it with the --release flag.
it then causes a [1] 25032 segmentation fault and crashes.
This is my main.rs file that i used:
use bevy::prelude::*;
fn main() {
App::new().add_plugins(DefaultPlugins).run();
}
and the Cargo.toml
[package]
name = "game"
version = "0.1.0"
edition = "2021"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
bevy = { git = "https://github.com/bevyengine/bevy.git", rev = "a830530be4398fb0832992e5b4baefc316d1f1d0" }
What went wrong
It compiled successfully, linked successfully, yet crashed.
Additional information
Other information that can be used to further reproduce or isolate the problem.
This commonly includes:
Logs:
Finished release [optimized] target(s) in 0.45s
Running `target/release/game`
2023-10-26T16:09:26.436047Z INFO bevy_render::renderer: AdapterInfo { name: "Apple M2", vendor: 0, device: 0, device_type: IntegratedGpu, driver: "", driver_info: "", backend: Metal }
[1] 25981 segmentation fault cargo r --release
Workarounds:
Weirdly enough, it works fine if i use
[profile.release]
opt-level = 2
works and runs as expected.
so my guess is that it maybe related to how llvm in rust generates assembly or maybe a ffi issue on wgpu ? no clue tbh. too many possibilities.
Debug Info
(lldb) r
Process 27795 launched: '/Users/robin/Desktop/game/target/release/game' (arm64)
2023-10-26T16:14:41.373263Z INFO bevy_render::renderer: AdapterInfo { name: "Apple M2", vendor: 0, device: 0, device_type: IntegratedGpu, driver: "", driver_info: "", backend: Metal }
2023-10-26 18:14:41.760596+0200 game[27795:244001] [plugin] AddInstanceForFactory: No factory registered for id <CFUUID 0x13be0f170> F8BB1C28-BAE8-11D6-9C31-00039315CD46
2023-10-26 18:14:41.769491+0200 game[27795:244001] HALC_ShellDevice.cpp:2609 HALC_ShellDevice::RebuildControlList: couldn't find the control object
Process 27795 stopped
* thread #1, name = 'main', queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1d4aae10177e678)
frame #0: 0x0000000100d3a3cc game`wgpu_types::TextureFormat::required_features::h9347a814f19bf8ac + 20
game`wgpu_types::TextureFormat::required_features::h9347a814f19bf8ac:
-> 0x100d3a3cc <+20>: ldrb w11, [x9, x8]
0x100d3a3d0 <+24>: add x10, x10, x11, lsl #2
0x100d3a3d4 <+28>: br x10
0x100d3a3d8 <+32>: ret
so, maybe a wgpu issue ? maybe someone can determine that here and create a followup issue on wgpu's repo.
Bevy version
bevy = { git = "https://github.com/bevyengine/bevy.git", rev = "a830530be4398fb0832992e5b4baefc316d1f1d0" }
bevy = "0.11.3"
[Optional] Relevant system information
If you cannot get Bevy to build or run on your machine, please include:
Rust
the Rust version you're using (you can get this by running
cargo --version
)Bevy relies on the "latest stable release" of Rust
nightly should generally work, but there are sometimes regressions: please let us know!
the operating system or browser used, including its version
If your bug is rendering-related, copy the adapter info that appears when you run Bevy.
You should also consider testing the examples of our upstream dependencies to help isolate any setup-specific issue:
wgpu
for rendering problemswinit
for input and window managementgilrs
for gamepad inputsWhat you did
I've setup a simple bevy project, with a barebones applications through default plugins and run it with the
--release
flag. it then causes a[1] 25032 segmentation fault
and crashes.This is my
main.rs
file that i used:and the
Cargo.toml
What went wrong
It compiled successfully, linked successfully, yet crashed.
Additional information
Other information that can be used to further reproduce or isolate the problem. This commonly includes:
Logs:
Workarounds:
Weirdly enough, it works fine if i use
works and runs as expected. so my guess is that it maybe related to how llvm in rust generates assembly or maybe a ffi issue on wgpu ? no clue tbh. too many possibilities.
Debug Info
so, maybe a wgpu issue ? maybe someone can determine that here and create a followup issue on wgpu's repo.