Open mcclure opened 10 months ago
I've also observed these for a while. They can be avoided by requesting an instance with Backends::PRIMARY
instead of the default Backends::all()
, since they are caused by the GL backend.
I tested and this problem is Wayland exclusive. If I log out, log back in to "Ubuntu with xorg", and repeat the tests, I do not get the crash in either 0.16 or 0.18.
They can be avoided by requesting an instance with Backends::PRIMARY instead of the default Backends::all(), since they are caused by the GL backend.
Since not all systems have Vulkan, surely you want to include support for the GL backend?
Since not all systems have Vulkan, surely you want to include support for the GL backend?
Yeah, YMMV. All systems I care about do support Vulkan, and I believe the GL backend has some other bugs too, so turning it off made sense.
Issue still happens in 0.20:
Didn't happen in 0.19 because of another bug :/
A test program that uses many wgpu features, but otherwise is fairly simple, segfaults on exit when run with winit 0.29. I don't know if this is a winit problem or a wgpu problem but wgpu_hal is in the gdb backtrace. I'm filing here first.
The GDB backtrace looks like
DETAILS/REPRO
I have a project https://github.com/mcclure/webgpu-tutorial-rs . As the name suggests, it is a (mostly finished) WebGPU tutorial application. It is based on the hello-triangle example.
As of a few days ago, commit a8e1516 was running wgpu 0.16 and winit 0.29-beta (a very early 0.29 beta, so that it had still the 0.28 API surface). This week, I attempted to upgrade. In commit 50c079e I upgraded to winit 0.29 final (while keeping wgpu fixed at 0.16). This had the effect of making the application segfault at close time. Because 0.16 is old, I upgraded to wgpu 0.18. This lead to a different problem #4630, fixed in PR #4635. Because I am trying to test with 0.18 I backported to 0.18 in PR #4649 which you can find the example code for in branch webgpu-tutorial-0.18-fork. You can test by checking out the webgpu-tutorial-0.18-fork branch and running cargo run (or commit 50c079e for the 0.16 version). Warning: When run successfully, this example has audio which currently may be somewhat loud.
Notice I select rwh_05 in Cargo.toml as directed by the wgpu matrix channel.
Platform
I am running with Rust 1.73.0 on Ubuntu 23.10 with Wayland and an almost entirely stock desktop environment. I am on a "Lenovo ThinkPad T14 Gen 3" with gpu "AMD Ryzen™ 5 PRO 6650U with Radeon™ Graphics × 12". The failure occurs 100% of the time. I have not tested on other platforms.
Both the 0.16 and 0.18 wgpu branch implicated wgpu_hal in the bt, though I don't think they were the same bt.
Expected behavior
In Rust, even if I do something wrong, I should get a panic with a clear error message rather than a segfault.
Note
I would be happy to file this bug on winit instead (since it was upgrading winit, not upgrading wgpu, that caused the problem) but I need to be able to plausibly say "I asked wgpu and they said it's not their fault (even though their frames are all over the gdb stack)".