Another run example error: cargo run --example tour

[huangjj27]

I'm trying to run the example on my Windows 10, but I come across this:

iced> $Env:RUST_BACKTRACE="full"
iced> cargo run --example tour  
    Finished dev [unoptimized + debuginfo] target(s) in 0.63s
     Running `target\debug\examples\tour.exe`
[2019-12-01T05:21:46Z INFO  winit::platform_impl::platform::window] Guessed window DPI factor: 1
error: process didn't exit successfully: `target\debug\examples\tour.exe` (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)

I tried to backtrace the log, But it seems to only print a line of log about DPI factor. How could I log more to locate this issue?

[ejmahler]

I'm currently having the same problem. I'm also on windows 10. If I try to run any example, I get the same error as above.

I attached visual studio's debugger to the counter example, and got this:

counter.exe!ash::vk::KhrSwapchainFn::create_swapchain_khr(ash::vk::Device self, ash::vk::SwapchainCreateInfoKHR * device, ash::vk::AllocationCallbacks * p_create_info, ash::vk::SwapchainKHR * p_allocator) Line 44899	Unknown
counter.exe!ash::extensions::khr::swapchain::Swapchain::create_swapchain(ash::vk::SwapchainCreateInfoKHR * self, core::option::Option<ash::vk::AllocationCallbacks*> create_info) Line 76	Unknown
counter.exe!gfx_backend_vulkan::device::{{impl}}::create_swapchain(gfx_backend_vulkan::Device * self, gfx_backend_vulkan::window::Surface * surface, gfx_hal::window::SwapchainConfig config, core::option::Option<gfx_backend_vulkan::window::Swapchain> provided_old_swapchain) Line 2093	Unknown
counter.exe!gfx_backend_vulkan::window::{{impl}}::configure_swapchain(gfx_backend_vulkan::window::Surface * self, gfx_backend_vulkan::Device * device, gfx_hal::window::SwapchainConfig config) Line 448	Unknown
counter.exe!wgpu_native::device::device_create_swap_chain<gfx_backend_vulkan::Backend>(wgpu_native::hub::Global * global, wgpu_native::id::Id<wgpu_native::device::Device<gfx_backend_empty::Backend>> device_id, wgpu_native::id::Id<wgpu_native::instance::Surface> surface_id, wgpu_native::swap_chain::SwapChainDescriptor * desc) Line 2093	Unknown
counter.exe!wgpu_native::device::wgpu_device_create_swap_chain(wgpu_native::id::Id<wgpu_native::device::Device<gfx_backend_empty::Backend>> device_id, wgpu_native::id::Id<wgpu_native::instance::Surface> surface_id, wgpu_native::swap_chain::SwapChainDescriptor * desc) Line 2126	Unknown
counter.exe!wgpu::Device::create_swap_chain(wgpu::Surface * self, wgpu_native::swap_chain::SwapChainDescriptor * surface) Line 834	Unknown
counter.exe!iced_wgpu::renderer::target::new_swap_chain(wgpu::Surface * surface, unsigned short width, unsigned short height, wgpu::Device * device) Line 80	Unknown
counter.exe!iced_wgpu::renderer::target::{{impl}}::new<winit::window::Window>(winit::window::Window * window, unsigned short width, unsigned short height, float dpi, iced_wgpu::renderer::Renderer * renderer) Line 46	Unknown
counter.exe!iced_winit::application::Application::run<iced::application::Instance<counter::Counter>>(iced_winit::settings::Settings settings) Line 120	Unknown
counter.exe!iced::application::Application::run<counter::Counter>(iced::settings::Settings settings) Line 144	Unknown
counter.exe!iced::sandbox::Sandbox::run<counter::Counter>(iced::settings::Settings settings) Line 129	Unknown
counter.exe!counter::main() Line 13	Unknown

It successfully creates the window, titles it, etc, but it stays empty for a few seconds, and then closes. It looks like it crashes when trying to create the vulkan environment. The actual crash looks deep within the vulkan driver -- it isn't crashing literally on this line, but the call stack gets mangled after this.

The actual error I get when attached is this:
Exception thrown at 0x00007FFD5E42E846 (ig9icd64.dll) in counter.exe: 0xC0000005: Access violation reading location 0x00000000000001B8.

So something has a null pointer to a struct or array, and it's trying to read 440 bytes into that struct/array.

[hecrj]

@ejmahler Is this a recent regression? Were you able to run the examples before?

If that is the case, could you try to rollback to 811d8b9 and see if the issue is still there? Also, wgpu-native released a new patch 3 days ago. You could try to lock the version to the previous one: 0.4.0.

[ejmahler]

I tried fixing wgpu-native to 0.4.0 by adding a line in iced/wgpu/cargo.toml reading "wgpu-native="=0.4.0", and got the same crash as before.

I tried the example revision you shared, and got the same crash as before.

I tried going back to the first revision of the tour.rs example (https://github.com/hecrj/iced/tree/5286ef36b6a5eb6846b5675a7a4aced72601df3b)I could find, but I couldn't compile right away. I had to go into iced/winit/cargo.toml and change the "winit" version to winit = "=0.20.0-alpha3" so that it wouldn't select alpha4. After that, it compiles, but when I try to run it, it crashes with a different error thread 'main' panicked at 'No adapters found. Please enable the feature for one of the graphics backends: vulkan, metal, dx12, dx11, gl', src\libcore\option.rs:1188:5.

I guessed that this was a problem with an older version of wgpu, so I went to the oldest version of iced that uses wgpu 0.4. I get this error when trying to compile. It looks like it's referencing a deleted branch of wgpu_glyph: Unable to update https://github.com/hecrj/wgpu_glyph?branch=feature/scissoring Caused by: failed to find branch feature/scissoring

So I tried to use the oldest revision that uses a valid version of wgpu_glyph, which is this: https://github.com/hecrj/iced/tree/c6edc75f588ace61fc2bb2eacf9f26b08d3bda0c This revision crashes with the original crash.

Desperate to get anything working, I went back to a random even older revision of the tour: https://github.com/hecrj/iced/tree/f9de39ddaa3020a9585b1648afb0ead45dfd7aa9/examples/tour

This compiles and runs without any problems. I'll keep digging to see if I can find a more recent revision that runs. In the meantime, do you have any advice for the "No adapters found." error? It might be as simple as enabling a feature or fixing a different version of a library. Also, do you have a local copy of wgpu_glyph's "scissoring" branch that i can use?

[ejmahler]

Update: I figured out that for the adapter error, I need to modify iced/wgpu/cargo.toml so that the wgpu version looks like this: wgpu = {version="0.3", features=["vulkan"]}

Based on that, the following revision from october 5th, crashes with the original error: https://github.com/hecrj/iced/tree/ae56edc8ccd3462766071cc00c12e92feccf1274

Since I can select my backend by editing this file, I tried setting the graphics backend to dx12 instead of vulkan. When I do this, the example compiles and runs. I'd like to try selecting the dx12 backen in the latest version of iced, but it's not clear to me how to select a backend with wgpu 0.4.

[hecrj]

@ejmahler wgpu chooses a suitable backend at runtime now. I am not sure if it should be using Vulkan on Windows by default if DirectX 12 is available. You should be able to change this line to BackendBit::DX12 to force it:

https://github.com/hecrj/iced/blob/6a0e442ad68c2b104b7e91ef80798610a79aca6b/wgpu/src/renderer.rs#L53

[ejmahler]

When I change that line of code to directly specify dx12, the examples in the latest version of iced work for me.

[hecrj]

@ejmahler Good to know! It may be an issue with your Vulkan driver, or maybe a bug in the Vulkan backend of gfx-hal.

Just for the record, do you have a dedicated GPU besides your Intel integrated graphics? I am not sure, but it may be that forcing the DirectX 12 backend is making wgpu choose your dedicated GPU.

[ejmahler]

Yes, I've got a gtx 1070.

I updated my drivers during the process of troubleshooting this problem, so at minimum it's not a problem of outdated drivers.

[hecrj]

@ejmahler Interesting. Thanks!

We may be able to make this configurable for cases like these by using something like environment variables, at least while we get things sorted out... Maybe an ICED_WGPU_BACKEND?

[ejmahler]

I investigated your suspicion about choosing the wrong device, and you were right.

In Renderer.rs, I added a dbg!() line right after the statement that specifies the backend:

let adapter = Adapter::request(&RequestAdapterOptions {
    power_preference: PowerPreference::LowPower,
    backends: BackendBit::DX12,
})
.expect("Request adapter");

dbg!(adapter.get_info());

When BackendBit is dx12, this is the output:

[wgpu\src\renderer.rs:57] adapter.get_info() = AdapterInfo {
    name: "NVIDIA GeForce GTX 1070 Ti",
    vendor: 4318,
    device: 7042,
    device_type: DiscreteGpu,
}

When BackendBit is all(), this is the output:

[wgpu\src\renderer.rs:57] adapter.get_info() = AdapterInfo {
    name: "Intel(R) UHD Graphics 630",
    vendor: 32902,
    device: 16024,
    device_type: IntegratedGpu,
}

So it looks like it's choosing the wrong device. Perhaps integrated graphics chips don't support swap chains?

[hecrj]

Thank you so much for all the testing! It's very hard to debug bugs I cannot reproduce. I really appreciate it.

I'd bet it's either an issue with the Vulkan driver of your integrated GPU, or a bug upstream. I am guessing the issue will also happen with the wgpu examples. I think opening an issue there would be the next step to take.

[ejmahler]

I fixed the problem by updating my intel display drivers to the latest version. When I mentioned that I updated drivers before, I only updated my nvidia drivers, because I honestly forgot I even had anything else.

I think the fact that it chooses the intel adapter is troubling, but not at all an urgent priority, because at worst I can disable it.

[huangjj27]

@ejmahler thanks for All information！I‘ll try to update my GPU driver for my old AMD graphics first

[huangjj27]

Some experiment results:
step 1. change BackendBit::all() in render.rs:53 to BackendBit::DX12, and cargo run --example tour

result: compiled and run, but hangs for seconds and exits, with logs:

iced> cargo run --example tour
   Compiling iced_wgpu v0.1.0 (C:\Users\huangjj27\Documents\codes\iced\wgpu)
   Compiling iced v0.1.0-beta (C:\Users\huangjj27\Documents\codes\iced)
    Finished dev [unoptimized + debuginfo] target(s) in 18.48s
     Running `target\debug\examples\tour.exe`
error: process didn't exit successfully: `target\debug\examples\tour.exe` (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)

step 2. change to BackendBit::DX11. exactly same error returns
step 3. change to original BackendBit::all(). exactly same error returns

Environment

OS: Windows 10 Pro 1909
Processer: AMD A10-5750M with Radeon(tm) HD graphics
Graphics: AMD Radeon HD 8650G + AMD Radeon HD 8790M (Microsoft detected dirvers, date to 2019/8/16, driver version: 26.20.12028.2) (Not update to AMD drivers for the super slow download.)

Update: After adding many dbg!, it turns out in my case, the windows crashed even berfore Adapter has finished it request, So it's probably wgpu::wgn::wgpu_request_adapters fault.

[huangjj27]

It seens that the issue is caused by gfx-rs/wgpu#368

[hecrj]

@huangjj27 Thanks for reporting back! This is related to #48 and #69.

I've been meaning to help fix that. I know a bunch of wgpu users that have been affected by it.

[vladikoff]

I seem to have a similar crash with examples:

RUST_BACKTRACE=1 cargo run --example counter
    Finished dev [unoptimized + debuginfo] target(s) in 0.18s
     Running `target/debug/examples/counter`
xkbcommon: ERROR: Key "<CAPS>" added to modifier map for multiple modifiers; Using Mod3, ignoring Lock
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:378:21
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.37/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.37/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:76
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:60
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1030
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1412
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:64
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:196
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:210
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:473
  11: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:380
  12: rust_begin_unwind
             at src/libstd/panicking.rs:307
  13: core::panicking::panic_fmt
             at src/libcore/panicking.rs:85
  14: core::panicking::panic
             at src/libcore/panicking.rs:49
  15: core::option::Option<T>::unwrap
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libcore/macros.rs:12
  16: wgpu_request_adapter
             at /home/vladfilippov/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.4.1/src/instance.rs:474
  17: wgpu::Adapter::request
             at /home/vladfilippov/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-0.4.0/src/lib.rs:545
  18: iced_wgpu::renderer::Renderer::new
             at wgpu/src/renderer.rs:51
  19: <iced_wgpu::renderer::Renderer as iced_native::renderer::windowed::Windowed>::new
             at wgpu/src/renderer.rs:417
  20: iced_winit::application::Application::run
             at ./winit/src/application.rs:129
  21: iced::application::Application::run
             at ./src/application.rs:140
  22: iced::sandbox::Sandbox::run
             at ./src/sandbox.rs:128
  23: counter::main
             at examples/counter.rs:4
  24: std::rt::lang_start::{{closure}}
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/rt.rs:64
  25: std::rt::lang_start_internal::{{closure}}
             at src/libstd/rt.rs:49
  26: std::panicking::try::do_call
             at src/libstd/panicking.rs:292
  27: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:80
  28: std::panicking::try
             at src/libstd/panicking.rs:271
  29: std::panic::catch_unwind
             at src/libstd/panic.rs:394
  30: std::rt::lang_start_internal
             at src/libstd/rt.rs:48
  31: std::rt::lang_start
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/rt.rs:64
  32: main
  33: __libc_start_main
  34: _start
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[Abendstolz]

Hm, I am curious which GPU would be chosen if the Highpower one is the requested adapter. (Instead of changing the backend bit)

https://github.com/hecrj/iced/blob/6a0e442ad68c2b104b7e91ef80798610a79aca6b/wgpu/src/renderer.rs#L52

My intuition says it should choose the Nvidia one then... I wonder if it would default to vulkan or dx12 though

[hecrj]

@Abendstolz Yes, wgpu tries to find an integrated device first unless the power preference is set to HighPerformance.

I think this is a good default for a GUI application. However, I understand there may be cases where an application may prefer to default to a powerful device. We could maybe make this configurable in the Settings struct.

[Abendstolz]

@hecrj I agree that it's a good default. A game will integrate iced on its own anyway and select the correct adapter.

I was merely curious because I have no system with an integrated and a standalone GPU available atm

[huangjj27]

Processer: AMD A10-5750M with Radeon(tm) HD graphics
Graphics: AMD Radeon HD 8650G + AMD Radeon HD 8790M

After some effort searching around the Internet, I found that these graphic cards don't support vulkan (the newest usable driver is in crimson 16.2.1, while the mininum vulkan supported version is 16.3).

Some facts that may be help

[ghost]

Wanted to try it for after I saw the release of 0.1 and I definitely get the same error. It initially crashed on all examples, so I went and tried the styling example with different backends.

For BackendBit::all() and BackendBit::VULKAN I get:

error: process didn't exit successfully: `target\debug\styling.exe` (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)
Segmentation fault

For BackendBit::GL I get:

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', C:\Users\Addile\.cargo\registry\src\github.com-1ecc6299db9ec823\wgpu-native-0.4.3\src\instance.rs:474:5        
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: process didn't exit successfully: `target\debug\styling.exe` (exit code: 101)

For BackendBit::DX11 I get a blank window that I can move around. When I try to resize it I get:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: WindowInUse(WindowInUse)', C:\Users\Addile\.cargo\registry\src\github.com-1ecc6299db9ec823\wgpu-native-0.4.3\src\device.rs:2091:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: process didn't exit successfully: `target\debug\styling.exe` (exit code: 101)

BackendBit::DX12 finally worked.

Laptop running Windows 10 with integrated Intel® HD Graphics 620 which should support DX11 and VULKAN. For example Vulkan details for it can be seen at https://vulkan.gpuinfo.org/displayreport.php?id=8035#device for driver 100.7922, I actually just updated today and have the newer 100.7985 driver version that isn't on the site yet.

If I can give any info that would help let me know.

[hecrj]

@AliciaMiedl Thanks for the detailed report!

The DX11 and GL backends of wgpu still need a bit more work.

Vulkan should work well, though. Could you try the wgpu examples (from the master and 0.4 branches)? If the master examples don't work, I believe reporting the issue there is the way to go.

[huangjj27]

With glow, the iced works. Thanks for everyone!