Crashes in wasm with wgpu

[stefnotch]

I wanted to use ArcShift in a wasm wgpu project, but quickly ran into

panicked at /rust/deps/dlmalloc-0.2.9/src/dlmalloc.rs:1200:9:
assertion failed: psize >= size + min_overhead

After some trial and error, I managed to get this code sample to reliable reproduce the crash. I do apologize for not proving a nice and easy reproduction project.

// Add a dependency on wgpu
// Compile to wasm32-unknown-unknown and run in the browser
struct Cute {
    pub texture: Option<wgpu::Texture>,
}


let foo = arcshift::ArcShift::new(Cute { texture: None });
log::info!("{:?}", foo.shared_non_reloading_get().texture.is_some());
std::mem::drop(foo);

web.js:865 panicked at /rust/deps/dlmalloc-0.2.9/src/dlmalloc.rs:1200:9:
assertion failed: psize >= size + min_overhead

Stack:

Error
    at http://localhost:5173/math3render/pkg/web.js?t=1754000352017:1383:21
    at logError (http://localhost:5173/math3render/pkg/web.js?t=1754000352017:5:18)
    at imports.wbg.__wbg_new_8a6f238a6ece86ea (http://localhost:5173/math3render/pkg/web.js?t=1754000352017:1382:66)
    at web.wasm.__wbg_new_8a6f238a6ece86ea externref shim (http://localhost:5173/math3render/pkg/web_bg.wasm:wasm-function[20266]:0x59bd5e)
    at web.wasm.console_error_panic_hook::Error::new::hada06d99acebcd14 (http://localhost:5173/math3render/pkg/web_bg.wasm:wasm-function[12174]:0x537454)
    at web.wasm.console_error_panic_hook::hook_impl::h5b4d8e6b4dee1256 (http://localhost:5173/math3render/pkg/web_bg.wasm:wasm-function[3529]:0x38f8c6)
    at web.wasm.console_error_panic_hook::hook::h11056c8a1349b2bb (http://localhost:5173/math3render/pkg/web_bg.wasm:wasm-function[22902]:0x5a5133)
    at web.wasm.core::ops::function::Fn::call::hfd229e704bdb1977 (http://localhost:5173/math3render/pkg/web_bg.wasm:wasm-function[14908]:0x56dc3d)
    at web.wasm.std::panicking::rust_panic_with_hook::h64448a2d0bc088de (http://localhost:5173/math3render/pkg/web_bg.wasm:wasm-function[7239]:0x48a9f7)
    at web.wasm.std::panicking::begin_panic_handler::{{closure}}::h637c06d29d466f9d (http://localhost:5173/math3render/pkg/web_bg.wasm:wasm-function[9191]:0x4dc41d)


(anonymous) | @ | web.js:865
-- | -- | --
  | logError | @ | web.js:5
  | imports.wbg.__wbg_error_7534b8e9a36f1ab4 | @ | web.js:859
  | $console_error_panic_hook::error::hb7cc8af0ddc3367f | @ | web_bg.wasm:0x532a08
  | $console_error_panic_hook::hook_impl::h5b4d8e6b4dee1256 | @ | web_bg.wasm:0x38f9c6
  | $console_error_panic_hook::hook::h11056c8a1349b2bb | @ | web_bg.wasm:0x5a5133
  | $core::ops::function::Fn::call::hfd229e704bdb1977 | @ | web_bg.wasm:0x56dc3d
  | $std::panicking::rust_panic_with_hook::h64448a2d0bc088de | @ | web_bg.wasm:0x48a9f7
  | $std::panicking::begin_panic_handler::{{closure}}::h637c06d29d466f9d | @ | web_bg.wasm:0x4dc41d
  | $std::sys::backtrace::__rust_end_short_backtrace::hd60e70d6c2b2c845 | @ | web_bg.wasm:0x5a8648
  | $__rustc[507298ddafb0ef2f]::rust_begin_unwind | @ | web_bg.wasm:0x57deaa
  | $core::panicking::panic_fmt::h8f223baba8ef14da | @ | web_bg.wasm:0x57ded7
  | $core::panicking::panic::h8d9c1055bcc34005 | @ | web_bg.wasm:0x56c8cb
  | $__rustc[507298ddafb0ef2f]::__rdl_dealloc | @ | web_bg.wasm:0x540ebe
  | $__rustc[507298ddafb0ef2f]::__rust_dealloc | @ | web_bg.wasm:0x59ea8a
  | $alloc::alloc::dealloc::h1a5c1d5233729119 | @ | web_bg.wasm:0x55a2d1
  | $arcshift::do_dealloc::h0082ef400e00c4ce | @ | web_bg.wasm:0x53eb71
  | $arcshift::raw_deallocate_node::hd711ee20e52934ff | @ | web_bg.wasm:0x59759f
  | $arcshift::do_drop_weak::hf561d418be432e4d | @ | web_bg.wasm:0x2e91bf
  | $arcshift::do_drop_strong::hc9245ac6e682b1dd | @ | web_bg.wasm:0x4c80c8
  | $<arcshift::ArcShift<T> as core::ops::drop::Drop>::drop::he5fb60df941af2ea | @ | web_bg.wasm:0x42933d
  | $core::ptr::drop_in_place<arcshift::ArcShift<render::application::Cute>>::haf7b5fdeacffd6d4 | @ | web_bg.wasm:0x5a5010
  | $core::mem::drop::h0ad95fbe9193aa67 | @ | web_bg.wasm:0x560a73
  | $render::application::Application::new::{{closure}}::h872c4e74b51e3e1c | @ | web_bg.wasm:0x10cc7c
  | $web::application::WasmApplication::new::{{closure}}::{{closure}}::h9730dde117ff43f4 | @ | web_bg.wasm:0x1a4929
  | $wasm_bindgen_futures::task::singlethread::Task::run::h6ba2fa0cbd9c092e | @ | web_bg.wasm:0x33f153
  | $wasm_bindgen_futures::queue::QueueState::run_all::h217e77ff646e6738 | @ | web_bg.wasm:0x31863d
  | $wasm_bindgen_futures::queue::Queue::new::{{closure}}::h297f57fb2721f99d | @ | web_bg.wasm:0x5442d7
  | $<dyn core::ops::function::FnMut<(A,)>+Output = R as wasm_bindgen::closure::WasmClosure>::describe::invoke::h1d43746d7c6b87d9 | @ | web_bg.wasm:0x504bfa
  | $closure1251 externref shim | @ | web_bg.wasm:0x599779
  | __wbg_adapter_62 | @ | web.js:320
  | real

[avl]

Thanks for the bug report.

Just to make sure: you are using multiple threads?

Does this always happen, as in "arcshift doesn't work at all", or only in some cases?

In the former case, I'd guess arcshift does some assumption which does not hold. Though I find that unexpected, given all the arcshift tests using miri.

If this only happens rarely, I think the problem is most likely elsewhere. The code snippet doesn't involve any threading, but it still looks like the heap has been corrupted. That other place could still be arcshift code, of course.

Is there other unsafe code in the same process? Does this happen even if the snippet in the report is the only arcshift-using code?

I'm not sure it's possible to use on wasm, but there is a "debug"-feature in arcshift that you might try and enable. It spams an enormous amount of log output to stdout. If you can reproduced the crash with this active, and attach the logs here, this might help figuring this one out.

[stefnotch]

Thank you for the quick and detailed response!
It happens always, and doesn't need multiple threads, and only needs that single bit of arcshift code. But it very much needs that particular wgpu struct. I'm guessing that its layout is especially weird.

With that, I managed to create a minimal reproduction project.

wasm-pack-template-master.zip

Make sure that you have the wasm-bindgen-cli. You can install it with

cargo install wasm-bindgen-cli

or

cargo binstall wasm-bindgen-cli

To compile this crate, do

cargo build --target=wasm32-unknown-unknown 
wasm-bindgen --target=web --out-dir=./pkg --debug ./target/wasm32-unknown-unknown/debug/demo.wasm

[stefnotch]

Okay, it's much easier to reproduce than I thought. It's sufficient to use an Arc inside an ArcShift, and then it crashes in wasm.

wasm-pack-template-master.zip

[avl]

Oh, that's fascinating!

Can you try and see if it's all types with drop impls, or if it really is just Arc that doesn't work.

I have three theories:

It doesn't work with Arc because of something with the layout of that type.

It doesn't work with Arc because it has a drop impls that somehow interferes with arcshift.

Something with 32 bit architectures causes the issue. The test bench is all 64 bit architectures (I just realized).

[stefnotch]

I just tried it with the following code. This still crashes

use wasm_bindgen::prelude::*;

#[wasm_bindgen(start)]
fn run() {
    std::panic::set_hook(Box::new(console_error_panic_hook::hook));
}

pub struct Demo {
    a: u32,
}

impl Drop for Demo {
    fn drop(&mut self) {
        // Okay this breaks
    }
}

#[wasm_bindgen]
pub fn greet() -> bool {
    let foo = arcshift::ArcShift::new(Demo { a: 3 });
    let result = foo.shared_non_reloading_get().a;
    std::mem::drop(foo);
    result > 0
}

Crash is

 panicked at /rust/deps/dlmalloc-0.2.9/src/dlmalloc.rs:1200:9:
assertion failed: psize >= size + min_overhead

Stack:

__wbg_get_imports/imports.wbg.__wbg_new_8a6f238a6ece86ea/<@http://127.0.0.1:7890/pkg/demo.js:162:21
logError@http://127.0.0.1:7890/pkg/demo.js:23:18
__wbg_get_imports/imports.wbg.__wbg_new_8a6f238a6ece86ea@http://127.0.0.1:7890/pkg/demo.js:161:66
demo.wasm.__wbg_new_8a6f238a6ece86ea externref shim@http://127.0.0.1:7890/pkg/demo_bg.wasm:wasm-function[391]:0x1741b
demo.wasm.console_error_panic_hook::Error::new::h4429473e99e2ec73@http://127.0.0.1:7890/pkg/demo_bg.wasm:wasm-function[212]:0x14b02
demo.wasm.console_error_panic_hook::hook_impl::h5c7da650703a4949@http://127.0.0.1:7890/pkg/demo_bg.wasm:wasm-function[56]:0xca01
demo.wasm.console_error_panic_hook::hook::h2231a20141607428@http://127.0.0.1:7890/pkg/demo_bg.wasm:wasm-function[321]:0x169a2
demo.wasm.core::ops::function::Fn::call::h4f14306bf3fad061@http://127.0.0.1:7890/pkg/demo_bg.wasm:wasm-function[268]:0x15d30
demo.wasm.std::panicking::rust_panic_with_hook::h64448a2d0bc088de@http://127.0.0.1:7890/pkg/demo_bg.wasm:wasm-function[133]:0x120f6
demo.wasm.std::panicking::begin_panic_handler::{{closure}}::h637c06d29d466f9d@http://127.0.0.1:7890/pkg/demo_bg.wasm:wasm-function[153]:0x12ebc
demo.wasm.std::sys::backtrace::__rust_end_short_backtrace::hd60e70d6c2b2c845@http://127.0.0.1:7890/pkg/demo_bg.wasm:wasm-function[414]:0x17560
demo.wasm.__rustc[507298ddafb0ef2f]::rust_begin_unwind@http://127.0.0.1:7890/pkg/demo_bg.wasm:wasm-function[350]:0x16f66
demo.wasm.core::panicking::panic_fmt::h8f223baba8ef14da@http://127.0.0.1:7890/pkg/demo_bg.wasm:wasm-function[351]:0x16f92
demo.wasm.core::panicking::panic::h8d9c1055bcc34005@http://127.0.0.1:7890/pkg/demo_bg.wasm:wasm-function[289]:0x162be
demo.wasm.__rustc[507298ddafb0ef2f]::__rdl_dealloc@http://127.0.0.1:7890/pkg/demo_bg.wasm:wasm-function[217]:0x14d32
demo.wasm.__rustc[507298ddafb0ef2f]::__rust_dealloc@http://127.0.0.1:7890/pkg/demo_bg.wasm:wasm-function[399]:0x174af
demo.wasm.alloc::alloc::dealloc::h2df93f31cc02d515@http://127.0.0.1:7890/pkg/demo_bg.wasm:wasm-function[173]:0x139b7
demo.wasm.arcshift::do_dealloc::h177991e786ec802f@http://127.0.0.1:7890/pkg/demo_bg.wasm:wasm-function[190]:0x141e8
demo.wasm.arcshift::raw_deallocate_node::h965fdd11787e06c0@http://127.0.0.1:7890/pkg/demo_bg.wasm:wasm-function[251]:0x1586e
demo.wasm.arcshift::do_drop_weak::hc614b83d18651ca6@http://127.0.0.1:7890/pkg/demo_bg.wasm:wasm-function[24]:0x7f1b
demo.wasm.arcshift::do_drop_strong::h958a1669c67a8241@http://127.0.0.1:7890/pkg/demo_bg.wasm:wasm-function[129]:0x11de1
demo.wasm.<arcshift::ArcShift<T> as core::ops::drop::Drop>::drop::h728c84f06f7360d3@http://127.0.0.1:7890/pkg/demo_bg.wasm:wasm-function[85]:0xf3b0
demo.wasm.core::ptr::drop_in_place<arcshift::ArcShift<demo::Demo>>::hf3ad02b2f61b0747@http://127.0.0.1:7890/pkg/demo_bg.wasm:wasm-function[318]:0x16907
demo.wasm.core::mem::drop::h0cd2cbeb042369ff@http://127.0.0.1:7890/pkg/demo_bg.wasm:wasm-function[263]:0x15bcd
demo.wasm.demo::greet::hd83c36a8180049bb@http://127.0.0.1:7890/pkg/demo_bg.wasm:wasm-function[88]:0xf746
demo.wasm.greet@http://127.0.0.1:7890/pkg/demo_bg.wasm:wasm-function[180]:0x13ced
greet@http://127.0.0.1:7890/pkg/demo.js:112:22
run@http://127.0.0.1:7890/index.html:16:39
async*@http://127.0.0.1:7890/index.html:19:9

[avl]

Thank you so much for your work.

I've reproduced the issue.

The problem is that an incorrect layout is calculated in arcshift. I think it's a bug in arcshift. I'm making some assumptions about the layout of repr(C) types that don't seem to hold. I'll continue to investigate.

I expect to have a fix soon.

[avl]

Ah, found the error. I think it's broken on all 32-bit platforms. I should have tested on 32 bit platforms, but it didn't occur to me to do it. Sorry about that!

The code implicitly assumes that there is no padding after the last non-payload item in the heap block allocated by arcshift.

Will fix. Once again, thanks for reporting!

[stefnotch]

Sweet, thank you for looking into this so quickly. Glad I could help with reproducing this issue.

I look forward to being able to use ArcShift again, instead of having to grapple with Arc<RwLock<>>

[avl]

PR: #20

[avl]

ArcShift 0.4.2 has been released, and should fully address this issue.

Please reopen this issue if the problem persists.

Thanks again for filing this bug report!