Executing twice the same instance results in a panic

[frochet]

Hello,

I am playing a bit with your implementation. I have a use case for which I would like to be able to instantiate once a wasm file and then call as much as I want the entry point of this wasm file. I did some modification to compile and instantiate without running the main function at instantiation time (in my use case, I would like to pre-load the wasm binary). I got the following backtrace when executing twice the main function of the same instance:

frochet@Attila:~/Documents/WebAssembly$ ./wasmtime/target/debug/wasmtime  --debug  --env=RUST_BACKTRACE=1 --dir=. --dir=/tmp demo/target/wasm32-wasi/debug/demo.wasm
Run the wasm file once
Run the wasm file a second time
thread 'main' panicked at 'assertion failed: c.borrow().is_none()', src/libstd/sys_common/thread_info.rs:37:26
thread 'main' panicked at 'Invoke error: StartTrap("wasm trap at 0x7f4ca98e0e37")', src/libcore/result.rs:999:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:59
             at src/libstd/panicking.rs:197
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:211
   4: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:474
   5: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:381
   6: rust_begin_unwind
             at src/libstd/panicking.rs:308
   7: core::panicking::panic_fmt
             at src/libcore/panicking.rs:85
   8: core::result::unwrap_failed
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/libcore/macros.rs:18
   9: core::result::Result<T,E>::expect
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/libcore/result.rs:827
  10: wasmtime::main
             at src/wasmtime.rs:300
  11: std::rt::lang_start::{{closure}}
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/libstd/rt.rs:64
  12: std::panicking::try::do_call
             at src/libstd/rt.rs:49
             at src/libstd/panicking.rs:293
  13: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:85
  14: std::rt::lang_start_internal
             at src/libstd/panicking.rs:272
             at src/libstd/panic.rs:394
             at src/libstd/rt.rs:48
  15: std::rt::lang_start
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/libstd/rt.rs:64
  16: main
  17: __libc_start_main
  18: _start

I am new to Rust, and my current understanding is too limited to narrow down the problem here. Do you have any idea on this?

[bjorn3]

(in my use case, I would like to pre-load the wasm binary)

When you are running a function from the same instance twice, they will share the same global memory. For example changing a static from one invocation will affect the other. This may not be what you want.

Do you have any idea on this?

I don't. I never contributed to wasmtime, only used it.

[frochet]

Hello! Thanks for your answer =)

(in my use case, I would like to pre-load the wasm binary)

When you are running a function from the same instance twice, they will share the same global memory. For example changing a static from one invocation will affect the other. This may not be what you want.

What I want is extending C host programs with small WebAssembly code that can be called as much as needed and store a state on its heap. So, I need this share global memory between calls, in the WebAssembly side.

Also, running the same instance several times for small programs (even without a heap) would also save me from the overhead of the compilation at each instantiation.

It seemed like this was easy to do with a light modification of Wasmtime. But I got this weird backtrace :/

Do you have any idea on this?

I don't. I never contributed to wasmtime, only used it.

[sunfishcode]

Hello! The wasm trap message means it's probably trapping in wasm code. Are you producing your wasm via either the Rust wasm32-wasi target or the was-sdk / clang wasm32-wasi targets? If so, calling the wasm start function means rerunning the libc startup code, which isn't really meant to be called multiple times. I don't know if that's what's causing the crash, but it could be, and in any case, it could be inefficient if you're calling it a lot. I'd suggest instead of calling the wasm start function multiple times, give the wasm module an export, and call the export multiple times.

Also, yes, better backtraces, error messages, and debugging are things we're aware of and are working on.

[frochet]

Hey!

Hello! The wasm trap message means it's probably trapping in wasm code. Are you producing your wasm via either the Rust wasm32-wasi target or the was-sdk / clang wasm32-wasi targets?

Indeed via Rust wasm32-wasi target

If so, calling the wasm start function means rerunning the libc startup code, which isn't really meant to be called multiple times.

That's a valuable piece of information :) Ok then I am not supposed to do that. I don't fully understand why invoking the start function of the module call the libc startup code. This should have been done at instantiate_wasi() call, right?

I don't know if that's what's causing the crash, but it could be, and in any case, it could be inefficient if you're calling it a lot. I'd suggest instead of calling the wasm start function multiple times, give the wasm module an export, and call the export multiple times.

So, I need to call the start function of the module once, but I don't want the module to run at instantiation time (I don't want the main function to execute at instantiation time). One way to avoid that would be not to have a main function into the wasm file and give an export to the module for the other functions to call?

Also, yes, better backtraces, error messages, and debugging are things we're aware of and are working on.

Great! This work and the oppurtunities it raises is really game changing, thanks!

[alexcrichton]

I believe that the wasmtime API crate has the necessary protections against this and the debugging experience has gotten better with better error messages and stack traces in the meantime, so closing.