Dynamic dispatch layer breaks on web #3430

i509VCB · 2023-01-27T21:06:17Z

Description
The web backend currently has an error like this when running the hello-triangle example using cargo run-wasm --example=hello-triangle in the browser console output:

panicked at 'assertion failed: wasm.is_instance_of::<T>()', wgpu/src/backend/web.rs:53:9

Stack:

getImports/imports.wbg.__wbg_new_abda76e883ba8a5f@http://localhost:8000/hello-triangle.js:340:21
console_error_panic_hook::Error::new::h09e78aee7fd991ae@http://localhost:8000/hello-triangle_bg.wasm:wasm-function[4182]:0xf15ec
console_error_panic_hook::hook_impl::h81c8bf5494034336@http://localhost:8000/hello-triangle_bg.wasm:wasm-function[717]:0x66f7d
console_error_panic_hook::hook::hc9dd7d1d176aa725@http://localhost:8000/hello-triangle_bg.wasm:wasm-function[4719]:0xf8b1e
core::ops::function::Fn::call::hc3d05c66054772b6@http://localhost:8000/hello-triangle_bg.wasm:wasm-function[3865]:0xec751
std::panicking::rust_panic_with_hook::hb42d415afcc11f2f@http://localhost:8000/hello-triangle_bg.wasm:wasm-function[1721]:0xaeb05
std::panicking::begin_panic_handler::{{closure}}::h57dd84c078404aa2@http://localhost:8000/hello-triangle_bg.wasm:wasm-function[2168]:0xc3482
std::sys_common::backtrace::__rust_end_short_backtrace::hef94dcc71d3b37f5@http://localhost:8000/hello-triangle_bg.wasm:wasm-function[5052]:0xfcef3
rust_begin_unwind@http://localhost:8000/hello-triangle_bg.wasm:wasm-function[3238]:0xe0f9f
core::panicking::panic_fmt::h32de9c76c9d5eb0c@http://localhost:8000/hello-triangle_bg.wasm:wasm-function[4581]:0xf6f1d
core::panicking::panic::hff08c7cf90edd9fe@http://localhost:8000/hello-triangle_bg.wasm:wasm-function[3862]:0xec692
<wgpu::backend::web::Identified<T> as core::convert::From<wgpu::context::ObjectId>>::from::h09e99484006351c1@http://localhost:8000/hello-triangle_bg.wasm:wasm-function[1664]:0xaba02
<T as wgpu::context::DynContext>::adapter_request_device::he51a22a86469d596@http://localhost:8000/hello-triangle_bg.wasm:wasm-function[668]:0x61f45
wgpu::Adapter::request_device::hdaaa471e221d3c58@http://localhost:8000/hello-triangle_bg.wasm:wasm-function[1073]:0x856fc
hello_triangle::run::{{closure}}::h19b0046d2265909e@http://localhost:8000/hello-triangle_bg.wasm:wasm-function[255]:0xb1d7

... Rest of call stack trimmed for brevity

Now this is not an error that is caused by mismatching types. By inserting some debugging aid log statements we see the following console output before the panic:

(0) Upcast(id = 74): wgpu::backend::web::Identified<web_sys::features::gen_GpuCanvasContext::GpuCanvasContext> [hello-triangle.js:489:17](http://localhost:8000/hello-triangle.js)
(1) Upcast(id = 72): wgpu::backend::web::Identified<web_sys::features::gen_GpuAdapter::GpuAdapter> [hello-triangle.js:489:17](http://localhost:8000/hello-triangle.js)
(2) Downcasting(id = 72): wgpu::backend::web::Identified<web_sys::features::gen_GpuAdapter::GpuAdapter> [hello-triangle.js:489:17](http://localhost:8000/hello-triangle.js)
(3) Downcasting(id = 72): wgpu::backend::web::Identified<web_sys::features::gen_GpuAdapter::GpuAdapter> [hello-triangle.js:489:17](http://localhost:8000/hello-triangle.js)
panicked at 'assertion failed: wasm.is_instance_of::<T>()', wgpu/src/backend/web.rs:61:9
...

What we see here is that the failure occurs on the second downcast of the GpuAdapter. The reason this occurs is because of how the web backend currently converts an ObjectId into whatever associated type is desired. In particular the web backend will use the ObjectId and convert the raw number right into whatever wasm_bindgen type was desired (such as GpuAdapter). Currently the web backend uses the IntoWasmAbi and FromWasmAbi traits to do this. However there is a less known side effect of this. FromWasmAbi and IntoWasmAbi transfer ownership of the JS object. When dropped, it will be destroyed on the JS side. Further use of the object when downcast again will of course fail since the actual object on the JS side was destroyed. It just happens to be caught easily by the is_instance_of check with strict asserts.

When running in release mode (to disable strict asserts) a different error shows up:

Uncaught (in promise) TypeError: getObject(...).requestDevice is not a function
    __wbg_requestDevice_7dbb93ae9dc5edc1 http://localhost:8000/hello-triangle.js:500
    __wbg_adapter_49 http://localhost:8000/hello-triangle.js:229
    real http://localhost:8000/hello-triangle.js:202
    promise callback*getImports/imports.wbg.__wbg_then_11f7a54d67b4bfad http://localhost:8000/hello-triangle.js:1128
    __wbg_adapter_49 http://localhost:8000/hello-triangle.js:229
    real http://localhost:8000/hello-triangle.js:202
    promise callback*getImports/imports.wbg.__wbg_then_cedad20fbbd9418a http://localhost:8000/hello-triangle.js:1132
    __wbg_adapter_49 http://localhost:8000/hello-triangle.js:229
    real http://localhost:8000/hello-triangle.js:202
    promise callback*getImports/imports.wbg.__wbg_then_11f7a54d67b4bfad http://localhost:8000/hello-triangle.js:1128
    finalizeInit http://localhost:8000/hello-triangle.js:1240
    init http://localhost:8000/hello-triangle.js:1272
    async* http://localhost:8000/:17
    EventListener.handleEvent* http://localhost:8000/:16

The solution to fix this would be to avoid taking ownership of the object when downcasting. This is easier said than done however. You need to make sure you destroy the object on drop to prevent memory leaks. The casting can be done, but we can only receive a ManuallyOwned<T>. And of course trying to return a reference to an object defined in a function is not allowed. This means there are one of two solutions left:

Replace ObjectId with a Box<dyn Whatever>

This would be an easy solution, but will cause a definite increase in memory allocations. It might not be a huge concern on either web or native as the largest allocation size would essentially be a pointer or two. Profiling would make sense here, but of course best to avoid an allocation heavy pattern if possible in the first place.

The web backend should store the underling Gpu* objects on the XXXXData associated types.

This does mean the ObjectId on web will become effectively inert (unless the expose-ids) feature is enabled. This will also automatically deal with the concerns around memory leaks by downcasting.

This solution however calls into question whether the dynamic dispatch layer should even have separate Data and Id types (consolidating instead on a Data type only. But the currently native implementation uses some Data associated types and future out of tree backends could use both.

Other notes

I tested this on firefox nightly (webgpu does not work on Linux at all on Chrome dev, no canary). The same error does appear in chrome dev even though the webgpy implementation on chrome is broken.

The text was updated successfully, but these errors were encountered:

codeart1st · 2023-01-29T11:53:21Z

Nice summary, had the same problems for now.

#3413 (comment)

expose-ids Feature is currently breaking the build.

   Compiling wgpu v0.15.0
error[E0599]: no method named `global_id` found for type `u32` in the current scope
  --> /home/plange/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/wgpu-0.15.0/src/backend/web.rs:58:16
   |
58 |             id.global_id(),
   |                ^^^^^^^^^ method not found in `u32`

error[E0609]: no field `1` on type `NonZeroU64`
  --> /home/plange/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/wgpu-0.15.0/src/backend/web.rs:69:16
   |
69 |             id.1,
   |                ^ unknown field

Some errors have detailed explanations: E0599, E0609.
For more information about an error, try `rustc --explain E0599`.

--

Chrome+Linux+WebGPU is still broken, but software rendering with swiftshader is working again. Try to use google-chrome-unstable --enable-unsafe-webgpu --enable-features=Vulkan,VulkanFromANGLE --use-angle=swiftshader

gents83 · 2023-02-02T20:14:34Z

Would it be possibile to keep the specific type inside the Identified and use the RefFromwasmAbi in order to not drop it in some way?

i509VCB · 2023-02-06T17:28:34Z

Would it be possibile to keep the specific type inside the Identified and use the RefFromwasmAbi in order to not drop it in some way?

It would be possible via having the dynamic dispatch layer downcast IDs into a ManuallyDrop and then get a reference from that.

The other solution I have in mind is to use the Data assoicated types to store the JS objects and leave the id to just being the wasm repr (without taking out the object) + global id.

marcofugaro · 2023-02-08T16:04:33Z

I've upgraded to 0.15.0 and yeah I have this same issue on the web

gents83 · 2023-02-20T06:34:24Z

Would it be possibile to keep the specific type inside the Identified and use the RefFromwasmAbi in order to not drop it in some way?

It would be possible via having the dynamic dispatch layer downcast IDs into a ManuallyDrop and then get a reference from that.

The other solution I have in mind is to use the Data assoicated types to store the JS objects and leave the id to just being the wasm repr (without taking out the object) + global id.

I was digging a bit into it yesterday, starting from what is happening on Surface, in order to see if I can implement this.
The idea then would be to have the data storing directly the object itself but it's not super clear to me how you would use the ObjectId and how do you imagine to do the conversions between the two (or maybe I didn't understand completely what is your idea 😅)

i509VCB · 2023-02-20T07:10:50Z

Would it be possibile to keep the specific type inside the Identified and use the RefFromwasmAbi in order to not drop it in some way?

It would be possible via having the dynamic dispatch layer downcast IDs into a ManuallyDrop and then get a reference from that.
The other solution I have in mind is to use the Data assoicated types to store the JS objects and leave the id to just being the wasm repr (without taking out the object) + global id.

I was digging a bit into it yesterday, starting from what is happening on Surface, in order to see if I can implement this. The idea then would be to have the data storing directly the object itself but it's not super clear to me how you would use the ObjectId and how do you imagine to do the conversions between the two (or maybe I didn't understand completely what is your idea 😅)

So the Context trait defines a bunch of assoicated types. My idea was to no longer downcast from ObjectId (making it just a global id) and store the GPUTexture for example inside the TextureData assoicated type. The same with every other type that holds a web_sys::GPU type

grovesNL · 2023-03-08T13:48:26Z

Is anyone actively working on this? It looks like it's blocking some projects using the WebGPU backend from switching to the new version. Should we consider backing out the changes for the WebGPU backend only, or trying to apply the solution mentioned above?

danec020 · 2023-03-08T17:40:51Z

I am also wondering on what is the progress of this issue? I am unable to test my WebGPU side of the project due to this issue. Or is there a easy work around?

i509VCB · 2023-03-08T17:42:31Z

We might as well try what I proposed. Arcinzation on native might require the dynamic dispatch layer to change anyways.

I've been incredibly busy however so I haven't had time to make the changes

cwfitzgerald · 2023-03-08T23:20:00Z

I wasn't working on it as I thought @i509VCB was working on it - I can prioritize it as it seems to be blocking.

armansito · 2023-03-12T18:45:23Z

Hello! It would be great if this could get prioritized as our WASM build and demos haven't been functioning since we updated to 0.15 due to this issue.

ten3roberts · 2023-03-20T08:50:16Z

How is the progress in solving this, as it seems to completely break wgpu 0.15 on the web for me and others?

Is there any suggested fix or workaround, or what is the plan for solving this issue?

codeart1st · 2023-03-20T09:13:38Z

Is there any suggested fix or workaround, or what is the plan for solving this issue?

Stay on an older version seems to be the only possible solution for now.

gents83 · 2023-03-20T19:16:04Z

As @i509VCB was saying previously it's possibile that It could be tackled while Arcanizing for #2710

eddyb · 2023-03-23T05:30:16Z

So there's a way to work around this massive (UAF-shaped) unsoundness issue. But it's not a good way to do it.
Basically you just comment out the dropObject function body in the resulting .js file:

function dropObject(idx) {
    // if (idx < 132) return;
    // heap[idx] = heap_next;
    // heap_next = idx;
}

No more free, no more problems (okay you're now leaking, which could be a problem for any transient objects).

After about a minute or two, it doesn't look too bad though (this starts out around 200 entries):

The risk here I suppose would be large objects being kept around, not necessarily many objects.

However, we can limit this to just WebGPU objects (i.e. the ones wgpu::backend::web is constantly freeing repeatedly due to ObjectId being Copy etc.):

const webgpu_classes = Object.getOwnPropertyNames(window)
    .filter(k => k.startsWith("GPU") && typeof window[k] === 'function')
    .map(k => window[k]);
const is_webgpu_obj = o => webgpu_classes.some(webgpu_class => o instanceof webgpu_class);
function dropObject(idx) {
    if(idx < 132) return;
    if(is_webgpu_obj(heap[idx])) return;
    heap[idx] = heap_next;
    heap_next = idx;
}

After triggering significantly more redraws than with the simpler method, I get:

And while Chrome itself using 1.6 GiB, the JS heap size is shown as 3 MiB, with less than 1 MiB leaked by that heap array (based on the contents, if I had to guess it's mostly GPURenderPassEncoder).

I'm also getting some lag-spikes but I think those are from XWayland (as I couldn't get WebGPU working natively).

Speaking of, this works with stable Chrome (Chrome/111.0.5563.64):

WAYLAND_DISPLAY= google-chrome-stable --enable-features=Vulkan --enable-unsafe-webgpu http://localhost:8000

And just as well with google-chrome-unstable (Chrome/113.0.5638.0 - that's the version I did most experimenting with, since I wasn't sure if the issue was older Chrome, but nope, both work just as well).

grovesNL · 2023-04-07T03:34:34Z

So the Context trait defines a bunch of assoicated types. My idea was to no longer downcast from ObjectId (making it just a global id) and store the GPUTexture for example inside the TextureData assoicated type. The same with every other type that holds a web_sys::GPU type

I started working on this in https://github.com/grovesNL/wgpu/tree/dynamic-dispatch-workaround but it's not clear how we could make this work without bigger changes to how ObjectId is used. I might be doing something wrong and misunderstood the approach you suggested though.

~~For example, Buffer is defined as~~

pub struct Buffer {
    id: ObjectId,
    /* ... snip ... */
}

A lot of functions just work with e.g., buffer.id, so we'd ideally have a way to get back toContext::BufferData from the ObjectId. I don't see a great way we could do that without going through the wasm ABI conversions again. In my branch you can remove the impl<T: FromWasmAbi<Abi = u32> + JsCast> From<ObjectId> for Sendable<T> to see most of the places I'm not sure about.

We also have some places accepting iterators like fn queue_submit<I: Iterator<Item = Self::CommandBufferId>> where we'd like to access Self::CommandBufferData instead. I'm not sure how we can deal with those either.

~~Edit: I think I'm past the problems with types like buffer now - still not sure about iterators~~

I'd like to change signatures like fn queue_submit<I: Iterator<Item = Self::CommandBufferId>> to include data with something like fn queue_submit<I: Iterator<Item = (Self::CommandBufferId, Self::CommandBufferData)>> but not sure how to make this work because of the type erasure.

Edit2: Figured out how to get past the iterator problem I was running into. Still working on filling in some other places now, but I have hello-triangle working again

I'll keep updating https://github.com/grovesNL/wgpu/tree/dynamic-dispatch-workaround as I work through it and open a PR once it's in slightly better shape.

grovesNL · 2023-04-08T03:25:22Z

I have a PR that should fix this at #3657 - would be great if some larger projects could test against my branch to see if I missed anything. I found it really easy to make mistakes doing the downcasting (would be great to improve this somehow), so it's possible there are some other paths that I didn't hit while testing.

davidar · 2023-04-08T09:38:18Z

@grovesNL I just tested https://compute.toys/ against your branch and can confirm it resolves this issue (and didn't notice any breakages)

maxammann · 2023-04-10T14:42:23Z

I have a PR that should fix this at #3657 - would be great if some larger projects could test against my branch to see if I missed anything. I found it really easy to make mistakes doing the downcasting (would be great to improve this somehow), so it's possible there are some other paths that I didn't hit while testing.

I can confirm that this works with maplibre-rs

codeart1st · 2023-04-11T15:14:52Z

I updated to cfc038a (codeart1st/wgpu-layers@2d425cb).
I still have problems with the dynamic dispatch from 0.15.

running 2 tests

test render_test::empty ... FAIL
test render_test::osm_pbf ... FAIL

failures:

---- render_test::empty output ----
    info output:
        surface: Surface { context: Context { type: "Web" }, id: ObjectId { id: Some(1) }, data: Any { .. }, config: Mutex { data: None } }
        adapter: Adapter { context: Context { type: "Web" }, id: ObjectId { id: Some(1) }, data: Any { .. } }
        device: Device { context: Context { type: "Web" }, id: ObjectId { id: Some(1) }, data: Any { .. } }
    
    error output:
        panicked at 'assertion failed: data.is::<T>()', /home/plange/.cargo/git/checkouts/wgpu-53e70f8674b08dd4/cfc038a/wgpu/src/context.rs:1045:5
        
        Stack:
        
        Error
            at http://127.0.0.1:8000/wasm-bindgen-test:772:21
            at logError (http://127.0.0.1:8000/wasm-bindgen-test:214:18)
            at imports.wbg.__wbg_new_abda76e883ba8a5f (http://127.0.0.1:8000/wasm-bindgen-test:771:66)
            at console_error_panic_hook::Error::new::haf64a5bfb729bfc4 (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[16653]:0x3f63c3)
            at console_error_panic_hook::hook_impl::hf098363f36624c01 (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[1962]:0x1eb4a3)
            at console_error_panic_hook::hook::habf82d241e6461f3 (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[18385]:0x40dff9)
            at core::ops::function::Fn::call::h2a5bfecfee992b11 (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[15758]:0x3e847e)
            at <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call::h3d3e4e50cd87f54b (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[11724]:0x39c7a4)
            at std::panicking::rust_panic_with_hook::h4e15c82b021ecc52 (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[283]:0x831c7)
            at std::panicking::begin_panic_handler::{{closure}}::h6314a820b4606399 (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[2202]:0x201a04)
        
        
    
    JS exception that was thrown:
        RuntimeError: unreachable
            at panic_abort::__rust_start_panic::abort::h63882360f46a9ea0 (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[20695]:0x423005)
            at __rust_start_panic (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[19866]:0x41e351)
            at rust_panic (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[1062]:0x177f29)
            at std::panicking::rust_panic_with_hook::h4e15c82b021ecc52 (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[283]:0x8331d)
            at std::panicking::begin_panic_handler::{{closure}}::h6314a820b4606399 (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[2202]:0x201a04)
            at std::sys_common::backtrace::__rust_end_short_backtrace::h902fac193e8faf01 (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[9550]:0x368232)
            at rust_begin_unwind (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[8462]:0x3495e1)
            at core::panicking::panic_fmt::h04349fcbd66ae3be (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[9326]:0x362260)
            at core::panicking::panic::h88c1f21fc10f4ca5 (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[7864]:0x336410)
            at wgpu::context::downcast_ref::h42cc43d9f477ee06 (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[8560]:0x34c54a)

---- render_test::osm_pbf output ----
    info output:
        surface: Surface { context: Context { type: "Web" }, id: ObjectId { id: Some(1) }, data: Any { .. }, config: Mutex { data: None } }
        adapter: Adapter { context: Context { type: "Web" }, id: ObjectId { id: Some(1) }, data: Any { .. } }
        device: Device { context: Context { type: "Web" }, id: ObjectId { id: Some(1) }, data: Any { .. } }
    
    error output:
        attempted to set a logger after the logging system was already initialized
        panicked at 'assertion failed: data.is::<T>()', /home/plange/.cargo/git/checkouts/wgpu-53e70f8674b08dd4/cfc038a/wgpu/src/context.rs:1045:5
        
        Stack:
        
        Error
            at http://127.0.0.1:8000/wasm-bindgen-test:772:21
            at logError (http://127.0.0.1:8000/wasm-bindgen-test:214:18)
            at imports.wbg.__wbg_new_abda76e883ba8a5f (http://127.0.0.1:8000/wasm-bindgen-test:771:66)
            at console_error_panic_hook::Error::new::haf64a5bfb729bfc4 (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[16653]:0x3f63c3)
            at console_error_panic_hook::hook_impl::hf098363f36624c01 (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[1962]:0x1eb4a3)
            at console_error_panic_hook::hook::habf82d241e6461f3 (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[18385]:0x40dff9)
            at core::ops::function::Fn::call::h2a5bfecfee992b11 (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[15758]:0x3e847e)
            at <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call::h3d3e4e50cd87f54b (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[11724]:0x39c7a4)
            at std::panicking::rust_panic_with_hook::h4e15c82b021ecc52 (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[283]:0x831c7)
            at std::panicking::begin_panic_handler::{{closure}}::h6314a820b4606399 (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[2202]:0x201a04)
        
        
    
    JS exception that was thrown:
        RuntimeError: unreachable
            at std::sys::wasm::common::abort_internal::h6f398f7e7f13bad3 (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[20689]:0x422fed)
            at std::panicking::rust_panic_with_hook::h4e15c82b021ecc52 (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[283]:0x837da)
            at std::panicking::begin_panic_handler::{{closure}}::h6314a820b4606399 (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[2202]:0x201a04)
            at std::sys_common::backtrace::__rust_end_short_backtrace::h902fac193e8faf01 (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[9550]:0x368232)
            at rust_begin_unwind (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[8462]:0x3495e1)
            at core::panicking::panic_fmt::h04349fcbd66ae3be (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[9326]:0x362260)
            at core::panicking::panic::h88c1f21fc10f4ca5 (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[7864]:0x336410)
            at wgpu::context::downcast_ref::h42cc43d9f477ee06 (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[8560]:0x34c54a)
            at <T as wgpu::context::DynContext>::surface_configure::hb2a817898dcae845 (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[5737]:0x2e532f)
            at wgpu::Surface::configure::h1da1cd9d521bcc3e (http://127.0.0.1:8000/wasm-bindgen-test_bg.wasm:wasm-function[840]:0x14c0db)

failures:

    render_test::empty
    render_test::osm_pbf

test result: FAILED. 0 passed; 2 failed; 0 ignored

cwfitzgerald · 2023-04-11T15:18:58Z

Is there any way of getting more of the stack? It cuts off right before the useful bit would be (seeing who is calling downcast_ref

grovesNL · 2023-04-11T15:29:27Z

Is this an offscreen canvas? I wasn't able to test that path and might need a small example to reproduce it.

codeart1st · 2023-04-11T15:46:34Z

I will try to reduce the code to get a better understanding about the problem. I thought the same about the offscreen canvas part, but the integration test with wasm-pack is a pure canvas, because we can't test in worker for now.

https://github.com/codeart1st/wgpu-layers/blob/main/tests/utils.rs#L33

More of the stack:

console.<computed> | @ | (index):16
-- | -- | --
  | (anonymous) | @ | wasm-bindgen-test:766
  | logError | @ | wasm-bindgen-test:214
  | imports.wbg.__wbg_error_f851667af71bcfc6 | @ | wasm-bindgen-test:764
  | $console_error_panic_hook::error::haa6344a57d53fd1a | @ | wasm-bindgen-test_bg.wasm:0x2fdebb
  | $console_error_panic_hook::hook_impl::hf098363f36624c01 | @ | wasm-bindgen-test_bg.wasm:0x1ec484
  | $console_error_panic_hook::hook::habf82d241e6461f3 | @ | wasm-bindgen-test_bg.wasm:0x410ec6
  | $core::ops::function::Fn::call::h2a5bfecfee992b11 | @ | wasm-bindgen-test_bg.wasm:0x3eb036
  | $<alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call::h3d3e4e50cd87f54b | @ | wasm-bindgen-test_bg.wasm:0x39edc3
  | $std::panicking::rust_panic_with_hook::h4e15c82b021ecc52 | @ | wasm-bindgen-test_bg.wasm:0x83edc
  | $std::panicking::begin_panic_handler::{{closure}}::h6314a820b4606399 | @ | wasm-bindgen-test_bg.wasm:0x2028f8
  | $std::sys_common::backtrace::__rust_end_short_backtrace::h902fac193e8faf01 | @ | wasm-bindgen-test_bg.wasm:0x36a345
  | $rust_begin_unwind | @ | wasm-bindgen-test_bg.wasm:0x34b3e0
  | $core::panicking::panic_fmt::h04349fcbd66ae3be | @ | wasm-bindgen-test_bg.wasm:0x36422b
  | $core::panicking::panic::h88c1f21fc10f4ca5 | @ | wasm-bindgen-test_bg.wasm:0x338204
  | $wgpu::context::downcast_ref::h42cc43d9f477ee06 | @ | wasm-bindgen-test_bg.wasm:0x34e349
  | $<T as wgpu::context::DynContext>::surface_get_capabilities::h627c650a19c22ea8 | @ | wasm-bindgen-test_bg.wasm:0x2dbfaa
  | $wgpu::Surface::get_capabilities::h1c786be24397c360 | @ | wasm-bindgen-test_bg.wasm:0x2bc9c9
  | $wgpu_layers::renderer::Renderer::new::{{closure}}::h508a1e824ff88dba | @ | wasm-bindgen-test_bg.wasm:0x375f5
  | $wgpu_layers::init::{{closure}}::h5b03158c392bbbee | @ | wasm-bindgen-test_bg.wasm:0x16a76d
  | $wgpu_layers::wasm::start_with_canvas::{{closure}}::h0b346edc917e180c | @ | wasm-bindgen-test_bg.wasm:0x13ff8b
  | $render_test::empty::{{closure}}::hc1b9759c6c9a0c78 | @ | wasm-bindgen-test_bg.wasm:0xd9422
  | $wasm_bindgen_test::__rt::Context::execute_async::{{closure}}::hbda9f82ade52a0f1 | @ | wasm-bindgen-test_bg.wasm:0x1bb160
  | $<wasm_bindgen_test::__rt::TestFuture<F> as core::future::future::Future>::poll::{{closure}}::{{closure}}::h79a9c56f52d3866a | @ | wasm-bindgen-test_bg.wasm:0x2eb8c4
  | $wasm_bindgen::convert::closures::invoke0_mut::ha7ed5b3e74ea5db6 | @ | wasm-bindgen-test_bg.wasm:0x30804d
  | __wbg_adapter_63 | @ | wasm-bindgen-test:454
  | cb0 | @ | wasm-bindgen-test:712
  | window.__wbg_test_invoke | @ | (index):26
  | (anonymous) | @ | wasm-bindgen-test:717
  | handleError | @ | wasm-bindgen-test:459
  | imports.wbg.__wbg_wbgtestinvoke_00cf1ac27b273033 | @ | wasm-bindgen-test:705
  | $wasm_bindgen_test::__rt::__wbg_test_invoke::h5503f87590057aa5 | @ | wasm-bindgen-test_bg.wasm:0x247ecf
  | $<wasm_bindgen_test::__rt::TestFuture<F> as core::future::future::Future>::poll::{{closure}}::ha5d162b17e4aac7a | @ | wasm-bindgen-test_bg.wasm:0x30d888
  | $scoped_tls::ScopedKey<T>::set::h03b4b7a9ba002906 | @ | wasm-bindgen-test_bg.wasm:0x29c2fd
  | $<wasm_bindgen_test::__rt::TestFuture<F> as core::future::future::Future>::poll::h910a1737cc6c3dca | @ | wasm-bindgen-test_bg.wasm:0x109362
  | $<wasm_bindgen_test::__rt::ExecuteTests as core::future::future::Future>::poll::hb676a32c2fa3065f | @ | wasm-bindgen-test_bg.wasm:0x8b767
  | $wasm_bindgen_test::__rt::Context::run::{{closure}}::he6d38dd0cefc076d | @ | wasm-bindgen-test_bg.wasm:0x1b285a
  | $wasm_bindgen_futures::future_to_promise::{{closure}}::{{closure}}::he0566893a7827a9d | @ | wasm-bindgen-test_bg.wasm:0x11d2aa
  | $wasm_bindgen_futures::task::multithread::Task::run::h93fbcdb073ef8b48 | @ | wasm-bindgen-test_bg.wasm:0x1414f0
  | $wasm_bindgen_futures::task::multithread::Task::spawn::{{closure}}::h2534fabdb3bf56f6 | @ | wasm-bindgen-test_bg.wasm:0x348ae0
  | $<dyn core::ops::function::FnMut<(A,)>+Output = R as wasm_bindgen::closure::WasmClosure>::describe::invoke::hf0acd6cac6bfa8a6 | @ | wasm-bindgen-test_bg.wasm:0x2ca927
  | __wbg_adapter_39 | @ | wasm-bindgen-test:276
  | real | @ | wasm-bindgen-test:253
  | Promise.then (async) |   |  
  | (anonymous) | @ | wasm-bindgen-test:1511
  | logError | @ | wasm-bindgen-test:214
  | imports.wbg.__wbg_then_ec5db6d509eb475f | @ | wasm-bindgen-test:1510
  | $js_sys::Promise::then::h0b2c7f0db6c57706 | @ | wasm-bindgen-test_bg.wasm:0x3730c7
  | $wasm_bindgen_futures::task::multithread::Task::run::h93fbcdb073ef8b48 | @ | wasm-bindgen-test_bg.wasm:0x141666
  | $wasm_bindgen_futures::task::multithread::Task::spawn::{{closure}}::h2534fabdb3bf56f6 | @ | wasm-bindgen-test_bg.wasm:0x348ae0
  | $<dyn core::ops::function::FnMut<(A,)>+Output = R as wasm_bindgen::closure::WasmClosure>::describe::invoke::hf0acd6cac6bfa8a6 | @ | wasm-bindgen-test_bg.wasm:0x2ca927
  | __wbg_adapter_39 | @ | wasm-bindgen-test:276
  | real | @ | wasm-bindgen-test:253
  | Promise.then (async) |   |  
  | (anonymous) | @ | wasm-bindgen-test:1511
  | logError | @ | wasm-bindgen-test:214
  | imports.wbg.__wbg_then_ec5db6d509eb475f | @ | wasm-bindgen-test:1510
  | $js_sys::Promise::then::h0b2c7f0db6c57706 | @ | wasm-bindgen-test_bg.wasm:0x3730c7
  | $wasm_bindgen_futures::task::multithread::Task::run::h93fbcdb073ef8b48 | @ | wasm-bindgen-test_bg.wasm:0x141666
  | $wasm_bindgen_futures::queue::QueueState::run_all::h958c10b773927cf1 | @ | wasm-bindgen-test_bg.wasm:0x17c4d2
  | $wasm_bindgen_futures::queue::Queue::new::{{closure}}::h7eaa64eab4ae83b0 | @ | wasm-bindgen-test_bg.wasm:0x348a62
  | $<dyn core::ops::function::FnMut<(A,)>+Output = R as wasm_bindgen::closure::WasmClosure>::describe::invoke::hf0acd6cac6bfa8a6 | @ | wasm-bindgen-test_bg.wasm:0x2ca927
  | __wbg_adapter_39 | @ | wasm-bindgen-test:276
  | real | @ | wasm-bindgen-test:253
  | Promise.then (async) |   |  
  | (anonymous) | @ | wasm-bindgen-test:1511
  | logError | @ | wasm-bindgen-test:214
  | imports.wbg.__wbg_then_ec5db6d509eb475f | @ | wasm-bindgen-test:1510
  | $js_sys::Promise::then::h0b2c7f0db6c57706 | @ | wasm-bindgen-test_bg.wasm:0x3730c7
  | $wasm_bindgen_futures::queue::Queue::schedule_task::h51ed02609d74f0d6 | @ | wasm-bindgen-test_bg.wasm:0x1f89e8
  | $wasm_bindgen_futures::task::multithread::Task::spawn::{{closure}}::h2f65c6375e41c6e5 | @ | wasm-bindgen-test_bg.wasm:0x3f92c1
  | $std::thread::local::LocalKey<T>::try_with::hbb0d1b9f9f4424a1 | @ | wasm-bindgen-test_bg.wasm:0x27b4f5
  | $std::thread::local::LocalKey<T>::with::h4d7fc6784dfd3778 | @ | wasm-bindgen-test_bg.wasm:0x37e906
  | $wasm_bindgen_futures::task::multithread::Task::spawn::h08edc717377ad9f1 | @ | wasm-bindgen-test_bg.wasm:0x12fa02
  | $wasm_bindgen_futures::spawn_local::h23c7a18a7df5b49c | @ | wasm-bindgen-test_bg.wasm:0x1c73f7
  | $wasm_bindgen_futures::future_to_promise::{{closure}}::h715c0534ead3bd7e | @ | wasm-bindgen-test_bg.wasm:0x2422e8
  | $wasm_bindgen::convert::closures::invoke2_mut::h163672718a4a560f | @ | wasm-bindgen-test_bg.wasm:0x2b07e3
  | __wbg_adapter_413 | @ | wasm-bindgen-test:478
  | cb0 | @ | wasm-bindgen-test:1495
  | (anonymous) | @ | wasm-bindgen-test:1500
  | logError | @ | wasm-bindgen-test:214
  | imports.wbg.__wbg_new_9d3a9ce4282a18a8 | @ | wasm-bindgen-test:1488
  | $js_sys::Promise::new::hfe2ac748ec399f05 | @ | wasm-bindgen-test_bg.wasm:0x3602f9
  | $wasm_bindgen_futures::future_to_promise::h142703004395576f | @ | wasm-bindgen-test_bg.wasm:0x2c2c13
  | $wasm_bindgen_test::__rt::Context::run::h0b07b3ab22dfcbee | @ | wasm-bindgen-test_bg.wasm:0xddd1a
  | $wasmbindgentestcontext_run | @ | wasm-bindgen-test_bg.wasm:0x247e30
  | run | @ | wasm-bindgen-test:569
  | main | @ | run.js:33
  | await in main (async) |   |  
  | (anonymous) | @ | run.js:39

If i don't rely on get_capabilities i get the same error for calling configure on my swapchain surface.

codeart1st · 2023-04-11T16:24:33Z

https://github.com/codeart1st/wgpu-wasm-dispatch

Removed a lot of code from the original library. I used the following command to start the tests with chromedriver.

wasm-pack test --chrome --all-features

Will try it also on my Windows 11 PC in Chrome. Maybe Linux is not the best testing place at the moment.

codeart1st · 2023-04-12T05:24:24Z

Today, I tried the wgpu-wasm-dispatch repo on Windows with Chrome Canary and got the same exception traces.
Version 114.0.5709.0 (Official Build) canary (64-bit)

94bryanr · 2023-04-14T04:52:59Z

Tried using OffscreenCanvas, still seeing an error.

... panicked at 'assertion failed: data.is::<T>()', ~/.cargo/git/checkouts/wgpu-53e70f8674b08dd4/f3bf0f7/wgpu/src/context.rs:1045:5

Thanks for the work on this!

codeart1st · 2023-04-18T15:22:54Z

I think the issue needs to be reopened or am I wrong?

maxammann · 2023-04-18T18:43:32Z

I think a new issue with a reproduction example is the way to go. This issue is fixed.

cwfitzgerald mentioned this issue Feb 1, 2023

Unable to run wgpu Cube example in Chrome Canary #3413

Closed

pixelspark mentioned this issue Feb 3, 2023

chore: upgrade crates (notably wgpu 0.15) webonnx/wonnx#140

Closed

i509VCB mentioned this issue Feb 6, 2023

Context dynamic dispatch #3051

Merged

3 tasks

jinleili mentioned this issue Feb 8, 2023

计算管线章节的示例运行报错 jinleili/learn-wgpu-zh#4

Closed

cwfitzgerald mentioned this issue Feb 11, 2023

15.1 Bug - assertion failed: wasm.is_instance_of::<T>() #3481

Closed

codeart1st mentioned this issue Feb 12, 2023

chore(deps): bump wgpu from 0.14.2 to 0.15.0 codeart1st/wgpu-layers#3

Merged

JolifantoBambla mentioned this issue Feb 15, 2023

Implement resolve query set (#3489 #3489

Merged

3 tasks

teoxoy added type: bug Something isn't working help required We need community help to make this happen. api: webgpu Issues with direct interface with WebGPU labels Feb 22, 2023

ten3roberts mentioned this issue Mar 1, 2023

Bumping wgpu from 0.14.2 to 0.15.1 AmbientRun/Ambient#168

Closed

codeart1st mentioned this issue Mar 8, 2023

Cube wasm example throws error in browser. #3568

Closed

armansito mentioned this issue Mar 12, 2023

WASM crashes linebender/vello#276

Closed

This was referenced Mar 22, 2023

run-wasm helper (cargo-run-wasm) for testing the wgpu runner on the web. EmbarkStudios/rust-gpu#1016

Closed

Update wgpu (and ash, to avoid duplicate deps). EmbarkStudios/rust-gpu#925

Merged

niklaskorz mentioned this issue Apr 7, 2023

Arcanization of wgpu core resources #3626

Merged

pixelspark mentioned this issue Apr 7, 2023

fix: replace 'type' with 'alias' in WGSL webonnx/wonnx#142

Closed

grovesNL mentioned this issue Apr 8, 2023

Avoid using WasmAbi functions on WebGPU backend #3657

Merged

3 tasks

mockersf mentioned this issue Apr 9, 2023

Webgpu support bevyengine/bevy#8336

Merged

maxammann mentioned this issue Apr 10, 2023

Upgrade to wgpu to fix issue on 0.15 maplibre/maplibre-rs#272

Merged

cwfitzgerald closed this as completed in #3657 Apr 10, 2023

davidar added a commit to compute-toys/wgpu-compute-toy that referenced this issue Apr 12, 2023

upgrade wgpu now that gfx-rs/wgpu#3430 is fixed

c82caf5

ten3roberts mentioned this issue Apr 18, 2023

Update to wgpu 0.16 AmbientRun/Ambient#308

Merged

codeart1st mentioned this issue Apr 20, 2023

wgpu(web) assertion failed: data.is::<T>() #3710

Closed

grovesNL mentioned this issue Jul 17, 2023

Add wasm-bindgen v0.2 handles for web_sys::HtmlCanvasElement and web_sys::OffscreenCanvas rust-windowing/raw-window-handle#134

Merged

petalas mentioned this issue Sep 1, 2023

wgpu(web): assertion failed: wasm.is_instance_of::<T>() #4108

Open

fr-an-k mentioned this issue Sep 24, 2023

Readme Lacks Documentation on Examples on Wasm #4169

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Dynamic dispatch layer breaks on web #3430

Dynamic dispatch layer breaks on web #3430

i509VCB commented Jan 27, 2023 •

edited

Loading

codeart1st commented Jan 29, 2023 •

edited

Loading

gents83 commented Feb 2, 2023

i509VCB commented Feb 6, 2023

marcofugaro commented Feb 8, 2023

gents83 commented Feb 20, 2023

i509VCB commented Feb 20, 2023

grovesNL commented Mar 8, 2023

danec020 commented Mar 8, 2023

i509VCB commented Mar 8, 2023 •

edited

Loading

cwfitzgerald commented Mar 8, 2023

armansito commented Mar 12, 2023

ten3roberts commented Mar 20, 2023

codeart1st commented Mar 20, 2023

gents83 commented Mar 20, 2023

eddyb commented Mar 23, 2023 •

edited

Loading

grovesNL commented Apr 7, 2023 •

edited

Loading

grovesNL commented Apr 8, 2023

davidar commented Apr 8, 2023

maxammann commented Apr 10, 2023

codeart1st commented Apr 11, 2023

cwfitzgerald commented Apr 11, 2023

grovesNL commented Apr 11, 2023

codeart1st commented Apr 11, 2023 •

edited

Loading

codeart1st commented Apr 11, 2023

codeart1st commented Apr 12, 2023 •

edited

Loading

94bryanr commented Apr 14, 2023

codeart1st commented Apr 18, 2023 •

edited

Loading

maxammann commented Apr 18, 2023

Dynamic dispatch layer breaks on web #3430

Dynamic dispatch layer breaks on web #3430

Comments

i509VCB commented Jan 27, 2023 • edited Loading

Other notes

codeart1st commented Jan 29, 2023 • edited Loading

gents83 commented Feb 2, 2023

i509VCB commented Feb 6, 2023

marcofugaro commented Feb 8, 2023

gents83 commented Feb 20, 2023

i509VCB commented Feb 20, 2023

grovesNL commented Mar 8, 2023

danec020 commented Mar 8, 2023

i509VCB commented Mar 8, 2023 • edited Loading

cwfitzgerald commented Mar 8, 2023

armansito commented Mar 12, 2023

ten3roberts commented Mar 20, 2023

codeart1st commented Mar 20, 2023

gents83 commented Mar 20, 2023

eddyb commented Mar 23, 2023 • edited Loading

grovesNL commented Apr 7, 2023 • edited Loading

grovesNL commented Apr 8, 2023

davidar commented Apr 8, 2023

maxammann commented Apr 10, 2023

codeart1st commented Apr 11, 2023

cwfitzgerald commented Apr 11, 2023

grovesNL commented Apr 11, 2023

codeart1st commented Apr 11, 2023 • edited Loading

codeart1st commented Apr 11, 2023

codeart1st commented Apr 12, 2023 • edited Loading

94bryanr commented Apr 14, 2023

codeart1st commented Apr 18, 2023 • edited Loading

maxammann commented Apr 18, 2023

i509VCB commented Jan 27, 2023 •

edited

Loading

codeart1st commented Jan 29, 2023 •

edited

Loading

i509VCB commented Mar 8, 2023 •

edited

Loading

eddyb commented Mar 23, 2023 •

edited

Loading

grovesNL commented Apr 7, 2023 •

edited

Loading

codeart1st commented Apr 11, 2023 •

edited

Loading

codeart1st commented Apr 12, 2023 •

edited

Loading

codeart1st commented Apr 18, 2023 •

edited

Loading