WASMs that I create crash Chrome unless the devtools are open

[riverfr0zen]

Bevy version

0.6.0

Operating system & version

• Ubuntu 21.10
• Linux unicron 5.13.0-28-generic 31-Ubuntu SMP Thu Jan 13 17:41:06 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
• NVIDIA Driver Version: 495.46
• Chrome 98.0.4758.80

What you did

I tried to build this 2D rect example in my project as a wasm target. (Note that I can view the example on that site without any issues in Chrome)

cargo build --example rect_eg --target wasm32-unknown-unknown

wasm-bindgen --out-dir examples/wasm/target --target web target/wasm32-unknown-unknown/debug/examples/rect_eg.wasm

You can see the failing project source here

What you expected to happen

I expected that when when I accessed the HTML file pointing to the wasm (over a web server), it would display the rectangle and that the browser would remain stable.

What actually happened

When I try to access the wasms I've created in Chrome (98.0.4758.80 on Ubuntu 21.10), the rectangle displays for a moment, but unless I have the developer tools open (by clicking Inspect), the browser tab crashes (or sometimes Chrome itself just flat out crashes).

Additional information

• If I have the dev tools open in Chrome, everything works fine/as expected.
• If I try to access via Firefox, everything works fine/as expected
• I also booted into Windows and tried to test my wasm (which I had generated on Linux) there, and it also crashed there unless I opened dev tools

The following is output from Chrome when it crashes:

[0204/174803.628690:ERROR:ptracer.cc(422)] ptrace: No such process (3)
[0204/174803.628712:ERROR:ptracer.cc(446)] Unexpected registers size 0 != 216
[0204/174803.628715:WARNING:process_reader_linux.cc(379)] Couldn't initialize main thread.
[0204/174803.675713:ERROR:scoped_ptrace_attach.cc(37)] process not stopped
[0204/174803.890453:ERROR:scoped_ptrace_attach.cc(37)] process not stopped
[0204/174803.890482:ERROR:scoped_ptrace_attach.cc(27)] ptrace: No such process (3)
[0204/174803.890492:ERROR:scoped_ptrace_attach.cc(27)] ptrace: No such process (3)
[0204/174803.890500:ERROR:scoped_ptrace_attach.cc(27)] ptrace: No such process (3)
[0204/174803.890507:ERROR:scoped_ptrace_attach.cc(27)] ptrace: No such process (3)
[0204/174803.890514:ERROR:scoped_ptrace_attach.cc(27)] ptrace: No such process (3)
[0204/174803.890522:ERROR:scoped_ptrace_attach.cc(27)] ptrace: No such process (3)
[0204/174803.890529:ERROR:scoped_ptrace_attach.cc(27)] ptrace: No such process (3)
[0204/174803.890536:ERROR:scoped_ptrace_attach.cc(27)] ptrace: No such process (3)
[0204/174803.890543:ERROR:scoped_ptrace_attach.cc(27)] ptrace: No such process (3)
[0204/174803.890550:ERROR:scoped_ptrace_attach.cc(27)] ptrace: No such process (3)
[0204/174803.890558:ERROR:scoped_ptrace_attach.cc(27)] ptrace: No such process (3)
[0204/174803.890566:ERROR:scoped_ptrace_attach.cc(27)] ptrace: No such process (3)
[0204/174803.890572:ERROR:scoped_ptrace_attach.cc(27)] ptrace: No such process (3)
[0204/174803.890578:ERROR:scoped_ptrace_attach.cc(27)] ptrace: No such process (3)
[0204/174803.890584:ERROR:scoped_ptrace_attach.cc(27)] ptrace: No such process (3)
[0204/174803.890590:ERROR:scoped_ptrace_attach.cc(27)] ptrace: No such process (3)
[0204/174803.890596:ERROR:scoped_ptrace_attach.cc(27)] ptrace: No such process (3)
[0204/174803.890602:ERROR:scoped_ptrace_attach.cc(27)] ptrace: No such process (3)
[0204/174803.890619:ERROR:scoped_ptrace_attach.cc(27)] ptrace: No such process (3)
[0204/174803.890625:ERROR:scoped_ptrace_attach.cc(27)] ptrace: No such process (3)
[0204/174803.890631:ERROR:scoped_ptrace_attach.cc(27)] ptrace: No such process (3)
[0204/174803.890661:ERROR:file_io_posix.cc(144)] open /proc/54187/auxv: Permission denied (13)
[0204/174803.890674:ERROR:process_memory.cc(41)] short read
[0204/174803.890699:ERROR:process_snapshot_linux.cc(78)] Couldn't read exception info
[0204/174803.891235:ERROR:scoped_ptrace_attach.cc(45)] ptrace: No such process (3)

If I have the developer tools open, everything works as expected. I do get the error below in the console log, but I believe it is expected.

rect_eg.js:1603 Uncaught (in promise) Error: Using exceptions for control flow, don't mind me. This isn't actually an error!
    at imports.wbg.__wbindgen_throw (rect_eg.js:1603:15)
    at wasm_bindgen::throw_str::h8e401d0f67754eb8 (rect_eg_bg.wasm:0x22d651d)
    at winit::platform_impl::platform::backend::throw::h531b3cf71a47d874 (rect_eg_bg.wasm:0x23a6362)
    at winit::platform_impl::platform::event_loop::EventLoop<T>::run::h559a9df9dbd65dac (rect_eg_bg.wasm:0x19f5278)
    at winit::event_loop::EventLoop<T>::run::haac6a08581092ff4 (rect_eg_bg.wasm:0x2089458)
    at bevy_winit::run::hb888c6e926570c1a (rect_eg_bg.wasm:0x20892e6)
    at bevy_winit::winit_runner_with::h44e91f337cbf6d9e (rect_eg_bg.wasm:0x9b5469)
    at bevy_winit::winit_runner::h18d6d36966529599 (rect_eg_bg.wasm:0x21e1617)
    at core::ops::function::Fn::call::hc945f559e333846d (rect_eg_bg.wasm:0x1f2bf83)
    at <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call::hf9a55069464dcd49 (rect_eg_bg.wasm:0x1b9c3e9)

[heavyrain266]

If you are running WebGPU backend instead of WebGL2 then looks like regression in Google's Dawn (canary) implementation of WebGPU compared with WGPU used in Firefox (nightly). If this is WebGL2 then looks like upstream problem caused by Chrome itself since you said it works in Firefox.

[riverfr0zen]

Appreciate the info @heavyrain266 . I'm new to this, so I'm not sure what "WebGPU backend instead of WebGL2" means in this context. My understanding according to this post was that generating the wasms in the way described therein (which is what I am doing) would leverage new built-in support for "a native WebGL2 backend to wgpu". If you can point me to a resource that shows how to switch between the cases you're describing (WGPU vs WebGL2 in Bevy 0.6.0), I'd appreciate it. Unless you are describing a dichotomy that existed pre-0.6.0?

In any case, is there any course of action I can take, or is this something that I should expect to get fixed upstream eventually?

[heavyrain266]

Appreciate the info @heavyrain266 . I'm new to this, so I'm not sure what "WebGPU backend instead of WebGL2" means in this context. My understanding according to this post was that generating the wasms in the way described therein (which is what I am doing) would leverage new built-in support for "a native WebGL2 backend to wgpu". If you can point me to a resource that shows how to switch between the cases you're describing (WGPU vs WebGL2 in Bevy 0.6.0), I'd appreciate it. Unless you are describing a dichotomy that existed pre-0.6.0?

In any case, is there any course of action I can take, or is this something that I should expect to get fixed upstream eventually?

By default Bevy 0.6 should use WebGL2 (OpenGL in the browser) but if you use Chrome canary or Frefox nightly with enabled WebGPU then Bevy will use Vulkan, Metal or DirectX 12 for renderer and in both cases if it fails to run in Chrome then looks like it's fully upstream problems caused by Chrome and their implementation of WebGL2/WebGPU if any other browser can run it just fine.

[riverfr0zen]

Ok, embarrassingly the issue was that I was not building with the "--release" argument. After seeing a discussion on Discord, I changed my build commands to:

cargo build --release --example rect_eg --target wasm32-unknown-unknown

wasm-bindgen --out-dir examples/wasm/target --target web target/wasm32-unknown-unknown/release/examples/rect_eg.wasm

and everything is working as expected. Thank you for your help and input, I learned some things!

[NiklasEi]

That's strange though. Are we expecting Wasm to error out in debug mode?

[mockersf]

Not really for such a small project... But Bevy currently musn't block in wasm or it's a crash, which I guess a release build could avoid

[colt-1]

This definitely seems like a problem still.

Version 98.0.4758.80 (Official Build) (arm64)
macOS 12.0.1 (21A559) M1 Pro

For those that find this, I was able to work around this with Trunk specifically doing: trunk serve --release

I played around with how this crashes in debug builds, and just having dev tools doesn't quite work for me. I need to wrap the wasm init inside a setTimeout of at least 20 seconds.

The crash is also super hard and seems to completely kill the dev tools, not really leaving much chance to see logs.