panic assertion failed intermitent crash compiled to WASM and running with libwebkit2gtk on Linux

[kellpossible]

Compiled using wasm-bindgen, via wasm-pack using the web target, and the --dev profile. This code is running in the webkit2gtk 2.28.4-1 browser on Archlinux.

Stack trace:

panicked at 'assertion failed: `(left != right)`
  left: `0`,
 right: `0`', ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/macros/mod.rs:16:9

<?>.wasm-function[console_error_panic_hook::Error::new::h11710926359e6a99]@[wasm code]
<?>.wasm-function[console_error_panic_hook::hook_impl::h43ac723b12164d7a]@[wasm code]
<?>.wasm-function[console_error_panic_hook::hook::h1509fc86d60f8ecc]@[wasm code]
<?>.wasm-function[core::ops::function::Fn::call::h63e0941c1aa82381]@[wasm code]
<?>.wasm-function[std::panicking::rust_panic_with_hook::h3e6619a8809a443a]@[wasm code]
<?>.wasm-function[rust_begin_unwind]@[wasm code]
<?>.wasm-function[core::panicking::panic_fmt::ha8209066b105fcdd]@[wasm code]
<?>.wasm-function[hashbrown::raw::inner::RawTable<T>::bucket::hfcb3cc32fba2684b]@[wasm code]
<?>.wasm-function[hashbrown::raw::inner::RawTable<T>::insert::h71a2e674faab18bc]@[wasm code]
<?>.wasm-function[indexmap::map::core::IndexMapCore<K,V>::push::h4f42c6dc20fce8fb]@[wasm code]
<?>.wasm-function[indexmap::map::core::IndexMapCore<K,V>::insert_full::h6cc9bd7b0982815d]@[wasm code]
<?>.wasm-function[indexmap::map::IndexMap<K,V,S>::insert_full::he19372e70f82483d]@[wasm code]
<?>.wasm-function[indexmap::map::IndexMap<K,V,S>::insert::h007a7c31241165e3]@[wasm code]
<?>.wasm-function[<indexmap::map::IndexMap<K,V,S> as core::iter::traits::collect::Extend<(K,V)>>::extend::{{closure}}::h396d242148f62446]@[wasm code]
<?>.wasm-function[core::iter::traits::iterator::Iterator::for_each::call::{{closure}}::hbb035c70f8777522]@[wasm code]
<?>.wasm-function[core::iter::adapters::map_fold::{{closure}}::h62be75b9f0a27adf]@[wasm code]
<?>.wasm-function[core::iter::adapters::filter_fold::{{closure}}::h268ff1624341ca8a]@[wasm code]
<?>.wasm-function[core::iter::adapters::map_fold::{{closure}}::hcf5aea4a2ef5e328]@[wasm code]
<?>.wasm-function[core::iter::traits::iterator::Iterator::fold::h853140cd02b11d69]@[wasm code]
<?>.wasm-function[<core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::fold::hf5d0ea58d414ae46]@[wasm code]
<?>.wasm-function[<core::iter::adapters::Filter<I,P> as core::iter::traits::iterator::Iterator>::fold::hfe2842f31b010ace]@[wasm code]
<?>.wasm-function[<core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::fold::h64e7ef0a45baccd6]@[wasm code]
<?>.wasm-function[core::iter::traits::iterator::Iterator::for_each::h5ba4ea97dae030ca]@[wasm code]
<?>.wasm-function[<indexmap::map::IndexMap<K,V,S> as core::iter::traits::collect::Extend<(K,V)>>::extend::h413750f7b641b695]@[wasm code]
<?>.wasm-function[<indexmap::map::IndexMap<K,V,S> as core::iter::traits::collect::FromIterator<(K,V)>>::from_iter::h49e190a53d106e85]@[wasm code]
<?>.wasm-function[<indexmap::set::IndexSet<T,S> as core::iter::traits::collect::FromIterator<T>>::from_iter::hc8ac9b46dc06688c]@[wasm code]
<?>.wasm-function[core::iter::traits::iterator::Iterator::collect::h6577e1d6120a2276]@[wasm code]
<?>.wasm-function[<yew::virtual_dom::Classes as core::convert::From<&str>>::from::hdb0a0b180f292b8c]@[wasm code]
<?>.wasm-function[<T as core::convert::Into<U>>::into::h22798bc94b25b76c]@[wasm code]

It's possible this may be related to rust-random/rand#1016 Perhaps it's a stability issue in libwebkit2gtk.

[Amanieu]

This is most likely a bug in IndexMap, can you open an issue there?

[kellpossible]

@Amanieu done 👍

[cuviper]

This is most likely a bug in IndexMap

Why do you think so?

panicked at 'assertion failed: `(left != right)`
...
<?>.wasm-function[hashbrown::raw::inner::RawTable<T>::bucket::hfcb3cc32fba2684b]@[wasm code]
<?>.wasm-function[hashbrown::raw::inner::RawTable<T>::insert::h71a2e674faab18bc]@[wasm code]
<?>.wasm-function[indexmap::map::core::IndexMapCore<K,V>::push::h4f42c6dc20fce8fb]@[wasm code]

It would appear to be this assertion:

hashbrown/src/raw/mod.rs

Line 505 in aa8c30b

debug_assert_ne!(self.bucket_mask, 0);

A 0 mask indicates a table with no capacity, so insert should have called reserve(1, hasher) before we got here.

[Amanieu]

Yes, but I don't understand why the reserve call didn't work. I was thinking that maybe you did weird things with the capacity in IndexMap.

[cuviper]

Eh, I don't know what weird things we could be doing to influence reserve. There's the hasher argument, but that only returns the u64 (or could panic). We do explicitly match our Vec capacity to the RawTable, but that should be independent.

[cuviper]

Wild guess -- maybe there was an allocation failure? Does WASM do anything weird with the OOM hook? That's supposed to diverge, so we'd get undefined behavior if that returned somehow...

[Amanieu]

I just had a look at all the functions in the backtrace starting from here and it all looks perfectly standard.

At this point I am strongly considering this could be a compiler bug...

[kellpossible]

@cuviper some additional context, this problem only seems to occur on startup of the application, so while I guess it's possible to be OOM, it seems unlikely. I'll try to better understand WASM memory allocation and monitor memory usage while testing to see if I can get some better info next time it happens

[kellpossible]

Could it also possibly be some unsafe code causing the issue? I don't have any in my code, but perhaps an underlying library, or interaction with Javascript that is broken? So far I haven't encountered this issue on Mac (webkit) or Windows (Edge, not chromium edge), which makes it all the more stranger, but I also haven't done as much testing on those platforms yet, so that is some anecdotal evidence suggesting that it is webkit2gtk specific. I'm hoping to switch my development setup to using Chromium to approach it from a different angle.

[cuviper]

What version of rustc are you using? It might be worth trying 1.47-beta, which is the first with LLVM 11.

[kellpossible]

I'm using 1.46 although at the time of reporting it could have been 1.45. I'll give 1.47 beta a try

[kellpossible]

Another crash today involving hashbrown using 1.47 beta, but a different stack trace, and different error message, not involving indexmap.

[Error] Unhandled Promise Rejection: Error: Out of bounds memory access (near '...e__h0039081c98c7cde6(arg0, arg1, addHeap...')
	<?>.wasm-function[hashbrown::raw::RawTable<T>::find::haa7d801b6993e649] (data:text/html,%3C…%3E:289:135)
	<?>.wasm-function[hashbrown::map::HashMap<K,V,S>::insert::he60509825cdbf93f]
	<?>.wasm-function[std::collections::hash::map::HashMap<K,V,S>::insert::h6360c5d503d5da4a]
	<?>.wasm-function[yew::virtual_dom::vtag::VTag::add_attributes::he5f5c99026bbf772]

[kellpossible]

And another crash which seems completely unrelated:

[Error] Unhandled Promise Rejection: Error: Unreachable code should not be executed (evaluating 'wasm.__wbindgen_start()')
    <?>.wasm-function[__rust_start_panic] (data:text/html,%3C…%3E:746)
    <?>.wasm-function[rust_panic]
    <?>.wasm-function[std::panicking::rust_panic_with_hook::h6c81660583233495]
    <?>.wasm-function[std::panicking::begin_panic_handler::{{closure}}::h35f4baddc401ed83]
    <?>.wasm-function[std::sys_common::backtrace::__rust_end_short_backtrace::h9f9c9a1ba07fa30f]
    <?>.wasm-function[rust_begin_unwind]
    <?>.wasm-function[core::panicking::panic_fmt::h29e09648cb9a0a7a]
    <?>.wasm-function[<wasm_bindgen::JsValue as core::ops::drop::Drop>::drop::h8f8e8a7ba387ed46]
    <?>.wasm-function[core::ptr::drop_in_place::h5d01315294578898]
    <?>.wasm-function[core::ptr::drop_in_place::h8a9fa6b94f654970]
    <?>.wasm-function[js_sys::global::get_global_object::h99770ed27eadef53]
    <?>.wasm-function[js_sys::global::GLOBAL::__init::h3814f4f2ded02b15]
    <?>.wasm-function[core::ops::function::FnOnce::call_once::hba8fa7df53943a1a]
    <?>.wasm-function[std::thread::local::lazy::LazyKeyInner<T>::initialize::h74fa9f2fbe1826a9]
    <?>.wasm-function[std::thread::local::statik::Key<T>::get::h24b7945b1c67fb6e]
    <?>.wasm-function[js_sys::global::GLOBAL::__getit::h6e9410677e1f915b]
    <?>.wasm-function[std::thread::local::LocalKey<T>::try_with::h603f7caab0a8af7a]
    <?>.wasm-function[std::thread::local::LocalKey<T>::with::he66d6e85b8524a51]
    <?>.wasm-function[js_sys::global::hf9ea7e1d6f157a7a]
    <?>.wasm-function[web_sys::window::h479c51bd53245a96]
    <?>.wasm-function[i18n_embed::requester::WebLanguageRequester::requested_languages::h087a7383ef02efe9]
    <?>.wasm-function[<i18n_embed::requester::WebLanguageRequester as i18n_embed::requester::LanguageRequester>::requested_languages::he9b116fc34fb7a29]

I've tried running this code about 100 times on a mac using web-view, but I can't replicate the issue there. I may have gotten the crash once on Windows, but can't be sure because there was no stack trace.

It's seeming more like it may either be:

• Compiler bug
• Unsafe, unsound code in some library/binding messing the party up for everyone
• A problem with webkit2gtk (but perhaps not because I might have triggered it in Windows on Edge, I'm not 100 percent sure though).

And not really a bug specific to hashbrown or indexmap

[Amanieu]

I'm going to cc @alexcrichton since this is likely a bug in the compiler or in the WASM implementation.

[Amanieu]

@kellpossible Could you give us instructions & code to reproduce this locally?

[alexcrichton]

I'd be happy to help dig in, but yeah having a way to rpeproduce would be quite helpful!

[kellpossible]

Thanks @alexcrichton @Amanieu Unfortunately it's not a public project yet, but I'll set aside some time this week to try and recreate it in a small project I can share here. The other problem is that it's very sporadic, maybe one in 30 runs or so.

[kellpossible]

I've not had the time to create a reproducible example that I can share, this issue appears to be exclusively occurring on libwebkit2gtk, perhaps it's a bug with the webassembly implementation there. After several weeks running my application in chomium and firefox I've yet to reproduce the issue in those browsers. I've also had some rendering issues exclusive to libwebkit2gtk so probably will ditch it at this point and use some other solution.