RuntimeError: Out of bounds memory access wasm.__wbindgen_start()

[t0muxx]

Describe the Bug

Hello

I'm reaching to you after having opened issues with leptos-rs and tauri :

• [bug] crashes : RuntimeError: Out of bounds memory access  tauri-apps/tauri#7154
• Random wasm.__wbindgen_start() crashes leptos-rs/leptos#1153

I am currently having "semi-random" crashes with all Tauri templates using wasm-bindgen (Leptos, Sycamore, Yew).
Tauri's team point of view is that this bug seems to come from wasm-bindgen.

Here is an example of what is happening :

(This time I had to Reload three times to trigger the crash, but sometimes it happens at first start)

(You can see the second time the application crashes directly)

Here is the stacktrace of the bug :

[Error] Unhandled Promise Rejection: RuntimeError: Out of bounds memory access (evaluating 'wasm.__wbindgen_start()')
	<?>.wasm-function[<core::cell::BorrowRefMut as core::ops::drop::Drop>::drop::hf42c085d7285d3bf] (test-ui-d856fd919585e10.js:612)
	<?>.wasm-function[core::ptr::drop_in_place<core::cell::BorrowRefMut>::h8315dbe9c700eb71]
	<?>.wasm-function[core::ptr::drop_in_place<core::cell::RefMut<leptos_dom::hydration::HydrationKey>>::h9149f27aa3a23070]
	<?>.wasm-function[leptos_dom::hydration::HydrationCtx::next_component::{{closure}}::h6883c5616db2da57]
	<?>.wasm-function[std::thread::local::LocalKey<T>::try_with::hb94a1e0a0aef6298]
	<?>.wasm-function[std::thread::local::LocalKey<T>::with::h89a5ada3f068daa0]
	<?>.wasm-function[leptos_dom::hydration::HydrationCtx::next_component::hc33f11bf247b26b6]
	<?>.wasm-function[leptos_dom::components::Component<F,V>::new::h465abdfae9683bc5]
	<?>.wasm-function[test_ui::app::App::hbad01cb3c50974fa]
	<?>.wasm-function[test_ui::main::{{closure}}::hde19ea94619b4cb6]
	<?>.wasm-function[leptos_dom::mount_to::{{closure}}::hd08507726cd06d49]
	<?>.wasm-function[leptos_reactive::runtime::RuntimeId::run_scope_undisposed::{{closure}}::h2390710064a783d0]
	<?>.wasm-function[leptos_reactive::runtime::with_runtime::{{closure}}::hfa3448a66d7673c7]
	<?>.wasm-function[std::thread::local::LocalKey<T>::try_with::hd4a7100a53c5c0c5]
	<?>.wasm-function[std::thread::local::LocalKey<T>::with::h30c6a5082ecc8b4b]
	<?>.wasm-function[leptos_reactive::runtime::with_runtime::h6a6a8e56b71ffd28]
	<?>.wasm-function[leptos_reactive::runtime::RuntimeId::run_scope_undisposed::h4069f30e99a0b11d]
	<?>.wasm-function[leptos_reactive::scope::create_scope::h5e625713b546d5da]
	<?>.wasm-function[leptos_dom::mount_to::hd2c03519c91041c3]
	<?>.wasm-function[leptos_dom::mount_to_body::h791b05ecb2e8fb8f]
	<?>.wasm-function[test_ui::main::h2310ebba16fb5874]
	<?>.wasm-function[core::ops::function::FnOnce::call_once::h684953229061ec4b]
	<?>.wasm-function[std::sys_common::backtrace::__rust_begin_short_backtrace::h68ebcd09cf1acae6]
	<?>.wasm-function[std::rt::lang_start::{{closure}}::h03c05521b45f41b4]
	<?>.wasm-function[std::rt::lang_start_internal::hbecc6ff7763fb2f1]
	<?>.wasm-function[std::rt::lang_start::h9cdb9a905687b1d8]
	<?>.wasm-function[main]
	<?>.wasm-function[]
	wasm-stub
	__wbg_finalize_init (test-ui-d856fd919585e10.js:612)

Steps to Reproduce

First i will say I don't know how to reproduce it directly with wasm-bindgen but you can reproduce it using Tauri this way :

1. Create a Tauri app using cargo create-tauri-app
2. Select Rust as front-end language
3. Select Leptos or Yew or Sycamore as UI template.
4. Now you can cd into the project directory
5. Run the app using cargo tauri dev
6. Open developer console to check for crashes
7. Right-Click Reload until you get the crashes

You can also use run AppImage : https://file.io/qV7is0fTatqw

Expected Behavior

The wasm.__wbindgen_start() should not crash

Additional Context

I would happily helps to fix this issue by submitting a PR, but I will need help to find out where this bug come from.

Thanks,

[Liamolucko]

I wasn't able to reproduce this, on either macOS or Manjaro Linux. Could you tell me what version of wasm-bindgen you're using, in case that has something to do with it?

[Liamolucko]

Scratch that actually, the template should be using the latest version of wasm-bindgen so if it's happening in the template it must be happening in the latest version. So, I'm not sure how to debug this further.

The error message reminds me of #3153, which was happening because init was getting called twice and resetting the wasm memory, but I don't see how that could be happening here since trunk only generates a single once-off init call.

[SIGSTACKFAULT]

in my context i'm calling init manually and i'm quite sure it's only getting called once

[t0muxx]

Thanks for your reply,

I can confirm you that the template is using version 0.2 by default :

wasm-bindgen = { version = "0.2", features = ["serde-serialize"] }

But even when I specify version = "0.2.86" I get the crash.

A test has been done on Pop!_Os (ubuntu based) and the crash happen too, but less often this time (to be noted that the machine running the Pop!_os has a lot more cpu resources).

I did another test in fresh Manjaro virtual machine and I reproduced the crash :

[Error] Unhandled Promise Rejection: RuntimeError: Out of bounds memory access (near '...e__h31f67d380e89dea9(arg0, arg1, addHeap...')
	<?>.wasm-function[<T as alloc::string::ToString>::to_string::h78049b9712ebcb71] (tet-ui-e492346f7f694496.js:224:135)
	<?>.wasm-function[<yew::virtual_dom::vnode::VNode as core::convert::From<T>>::from::hc4622367628a0d0d]
	<?>.wasm-function[<T as core::convert::Into<U>>::into::h59e849be70a107c7]
	<?>.wasm-function[<yew::utils::NodeSeq<IN,OUT> as core::convert::From<IN>>::from::h4715b4ebc797404c]
	<?>.wasm-function[<T as core::convert::Into<U>>::into::ha74799d1de54ebcb]
	<?>.wasm-function[<tet_ui::app::App as yew::functional::FunctionProvider>::run::app::h5627a23ac273eadb]
	<?>.wasm-function[<tet_ui::app::App as yew::functional::FunctionProvider>::run::h976a9f8b8db8f3bd]
	<?>.wasm-function[yew::functional::FunctionComponent<T>::render::hb6eef454e65879ab]
	<?>.wasm-function[<tet_ui::app::App as yew::html::component::BaseComponent>::view::h6964305c789320c5]
	<?>.wasm-function[<yew::html::component::lifecycle::CompStateInner<COMP> as yew::html::component::lifecycle::Stateful>::view::hca8ebf0fc8143b80]
	<?>.wasm-function[yew::html::component::lifecycle::ComponentState::render::h0d1910794859d6b1]
	<?>.wasm-function[<yew::html::component::lifecycle::RenderRunner as yew::scheduler::Runnable>::run::h07f6bc77cf92e6bf]
	<?>.wasm-function[yew::scheduler::start_now::scheduler_loop::h2391fca0bd1dcce6]
	<?>.wasm-function[yew::scheduler::start_now::{{closure}}::h9ebbc3ea421428d0]
	<?>.wasm-function[std::thread::local::LocalKey<T>::try_with::h7063850258b8f0e4]
	<?>.wasm-function[std::thread::local::LocalKey<T>::with::h3d5bf423c347928d]
	<?>.wasm-function[yew::scheduler::start_now::haef350ccb03f953b]
	<?>.wasm-function[yew::scheduler::arch::start::{{closure}}::h83e14fab35a13c99]
	<?>.wasm-function[wasm_bindgen_futures::task::singlethread::Task::run::h4422c07f2bb408aa]
	<?>.wasm-function[wasm_bindgen_futures::queue::QueueState::run_all::h999d32b47d843add]
	<?>.wasm-function[wasm_bindgen_futures::queue::Queue::new::{{closure}}::h53319a43ed85aba3]
	<?>.wasm-function[<dyn core::ops::function::FnMut<(A,)>+Output = R as wasm_bindgen::closure::WasmClosure>::describe::invoke::h31f67d380e89dea9]
	wasm-stub
	__wbg_adapter_21 (tet-ui-e492346f7f694496.js:224:135)
	real (tet-ui-e492346f7f694496.js:193)

To reproduce it I did :

1. Fresh manjaro installation
2. setup rustup
3. cargo install create-tauri-app tauri-cli trunk
4. Create a Tauri app using cargo create-tauri-app
5. Select Rust as front-end language
6. Select Leptos or Yew or Sycamore as UI template.
7. Run the app using cargo tauri dev
8. Open developer console to check for crashes
9. Right-Click Reload until you get the crashes

Note that I had to Right-Click->Reload many times to trigger the crash (sometimes 20+ times).

Do you have any clue on this ?

Thanks

[jrouaix]

Hello, just passing by, I'm having the same problem on an ubuntu.

[daxpedda]

I just remembered that I used the encounter something similar during testing in the past, reloading would sometimes throw random bugs like this. While debugging it, I came to the conclusion that the browser is doing some "destructive things" while tearing down the page, which is why some of these errors are strange, like memory errors or callback issues.

I found that not having the dev tools open helps and opening a new page will never trigger that bug, it only happens during refresh.

I can't actually confirm if this is the same bug I encountered, but you could try and see what happens if you don't open the dev tools.

[t0muxx]

Unfortunately this crash can happen when the application has just been started (without dev tools opened and no reload). This is how I discovered the crash.
You can see an example in this gif (second time AppImage is run triggers the crash) : https://user-images.githubusercontent.com/30345035/244290776-60640a75-e68c-4fca-a735-6aeb5d8d5950.gif

[daxpedda]

Ah that's unfortunate.

[jrouaix]

Hello here, i'm digging a little more on this issue here : https://github.com/jrouaix/wasm_pbm
Do you know who in the world could help on this issue ?

[daxpedda]

I think if you manage to remove the leptos dependency in the minimal example we should be able to figure this out here.
If this turns out to be beyond us we can always ask in the Bytecode Alliance Chat, but this isn't directly their area of expertise I think.

[jrouaix]

ok reported here :
https://bytecodealliance.zulipchat.com/#narrow/stream/206238-general/topic/WASM.20.2B.20Webkit2GTK.20.2B.20Linux.20.20.3D.3E.20random.20crashes

[campbellcole]

I am having this issue as well. I created a Tauri project using Leptos, and this started happening more and more the larger my project grew. It's at a point now where it happens about 90% of the time and I cannot continue development on my project anymore. Hoping a solution is found soon!

Edit: It is worth noting that the entire stack trace refers to functions in the nom crate. The only thing this crate is being used for in my project is as a dependency for the styled and stylist crates for scoped CSS. The stack trace is available here: https://pastebin.com/8Qq9FLZC

Edit 2: I removed both styled and stylist and the error no longer happens ever. I don't know what about the nom crate was causing this, but (at least in my case) the issue is now completely solved.

Edit 3 (more than a month later): I spoke much too soon. The error started reappearing after a few days and it slowly became more and more common as my codebase grew. It happens more than half the time, even after a reload. It's effectively disabled hot-reloading for me because it bricks itself trying to reload more often than not. It seems to happen more often the longer the app takes to initialize, which makes me think race condition, but of course I have no idea.

[SIGSTACKFAULT]

Just passing through to bump the thread and say it's also happening to me in a WASM Bevy game inside a Vue SPA which works fine on the web, but has this issue inside a Tauri app. Manjaro Linux.

This is blocking my ability to ship my app as a desktop app :(

[bicarlsen]

I've had the same issue for months now. I've had several Discord discussions regarding it with additional stack traces and context:

• Rust > wasm-bindgen
• Yew
• Tauri (1)
• Tauri (2)

[bicarlsen]

@icb on the Tauri team asked me to see if it breaks in GNOME-Web (Epiphany), and it does. So it seems the issue is with the interaction between wasm-bindgen and WebKitGTK.