In CI, my application called request_adapter() and wgpu panicked due to some sort of flake. Evidently this code path can fail due to external factors; therefore, it should not panic but return an error that can be retried and/or reported to the user. (Or maybe this is some kind of race condition bug analogous to acting on a closed file descriptor?)
thread 'tokio-runtime-worker' panicked at C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\wgpu-hal-0.18.0\src\gles\adapter.rs:194:26:
called `Result::unwrap()` on an `Err` value: Os { code: 2004, kind: Uncategorized, message: "The requested transformation operation is not supported." }
stack backtrace:
0: std::panicking::begin_panic_handler
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library\std\src\panicking.rs:595
1: core::panicking::panic_fmt
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library\core\src\panicking.rs:67
2: core::result::unwrap_failed
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library\core\src\result.rs:1652
3: enum2$<core::result::Result<tuple$<>,std::io::error::Error> >::unwrap
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33\library\core\src\result.rs:1077
4: wgpu_hal::gles::wgl::AdapterContext::lock
at C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\wgpu-hal-0.18.0\src\gles\wgl.rs:72
5: wgpu_hal::gles::Adapter::expose
at C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\wgpu-hal-0.18.0\src\gles\adapter.rs:194
6: wgpu_hal::gles::wgl::impl$11::enumerate_adapters
at C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\wgpu-hal-0.18.0\src\gles\wgl.rs:454
7: wgpu_core::instance::impl$6::request_adapter::gather<wgpu_hal::gles::Api,tuple$<> >
at C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\wgpu-core-0.18.0\src\instance.rs:834
8: wgpu_core::global::Global<wgpu_core::identity::IdentityManagerFactory>::request_adapter<wgpu_core::identity::IdentityManagerFactory>
at C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\wgpu-core-0.18.0\src\instance.rs:906
9: wgpu::backend::direct::impl$7::instance_request_adapter
at C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\wgpu-0.18.0\src\backend\direct.rs:613
10: wgpu::context::impl$5::instance_request_adapter<wgpu::backend::direct::Context>
at C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\wgpu-0.18.0\src\context.rs:2075
11: wgpu::Instance::request_adapter
at C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\wgpu-0.18.0\src\lib.rs:1880
12: test_wgpu::get_factory::async_fn$0
at .\tests\test-wgpu.rs:43
...
Platform
Microsoft Windows Server 2022 10.0.20348 (GitHub Actions)
(I've only seen this the once so far; I'm filing this issue in the spirit of "when dealing with hardware interfacing, write down all the edge-case happenings", not because it's causing any practical trouble.)
In CI, my application called
request_adapter()
and wgpu panicked due to some sort of flake. Evidently this code path can fail due to external factors; therefore, it should not panic but return an error that can be retried and/or reported to the user. (Or maybe this is some kind of race condition bug analogous to acting on a closed file descriptor?)https://github.com/gfx-rs/wgpu/blob/49b7ec97c164bac9ee877f45cdd806fbefecc5a4/wgpu-hal/src/gles/wgl.rs#L72
Platform
wgpu
0.18.0AdapterInfo { name: "Microsoft Basic Render Driver", vendor: 5140, device: 140, device_type: Cpu, backend: Dx12 }