Stream: git-wasmtime

Topic: wasmtime / issue #5325 Unexpted error "called `Option::un...

Wasmtime GitHub notifications bot (Nov 25 2022 at 13:06):

kpreisser opened issue #5325:

Hi,
we use Wasmtime 3.0.0 with wasmtime-dotnet in an application where we load a 8 MB .wasm file produced by the WASI SDK for .NET.

After instantiating the module and calling the exported _start function, we either get an access violation, or the following error is printed to the console and returned as trap (with RUST_BACKTRACE=full (this is on Windows 10 x64 (Build 19044)):

thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', crates\c-api\src\linker.rs:104:63
stack backtrace:
   0:     0x7ffdf2b36d42 - impl_new_epoch
   1:     0x7ffdf2b5283b - impl_new_epoch
   2:     0x7ffdf2b31f7a - impl_new_epoch
   3:     0x7ffdf2b39464 - impl_new_epoch
   4:     0x7ffdf2b3909a - impl_new_epoch
   5:     0x7ffdf2b39c51 - impl_new_epoch
   6:     0x7ffdf2b39b1a - impl_new_epoch
   7:     0x7ffdf2b3776f - impl_new_epoch
   8:     0x7ffdf2b39820 - impl_new_epoch
   9:     0x7ffdf2bf4a85 - _jit_debug_register_code
  10:     0x7ffdf2bf492c - _jit_debug_register_code
  11:     0x7ffdf2533d52 - wasm_foreign_delete
  12:     0x7ffdf259008d - wasm_globaltype_copy
  13:     0x7ffdf25b7cad - wasmtime_val_delete
  14:     0x7ffdf24edb09 - wasm_foreign_delete
  15:      0x1b7f0bfa26d - <unknown>
  16:      0x1b7f0bfa090 - <unknown>
  17:      0x1b7f0bf8501 - <unknown>
  18:      0x1b7f086102c - <unknown>
  19:      0x1b7f0c22bee - <unknown>
  20:      0x1b7f0c230eb - <unknown>
  21:     0x7ffdf2bb2c73 - _jit_debug_register_code
  22:     0x7ffdf25c2d74 - wasmtime_val_delete
  23:     0x7ffdf25d55f6 - wasm_tabletype_copy
  24:     0x7ffdf24f4ef7 - wasm_foreign_delete
  25:     0x7ffdf24f7de5 - wasm_foreign_delete
  26:     0x7ffdf25e3ed0 - wasmtime_func_call
  27:     0x7ffd9e0b0f8c - <unknown>
  28:     0x7ffd9e0b0c79 - <unknown>
  29:     0x7ffd9e0b08a3 - <unknown>
  30:     0x7ffd9e0b06b8 - <unknown>
  31:     0x7ffd9e0a553c - <unknown>
  32:     0x7ffd9e0a2eb1 - <unknown>
  33:     0x7ffdfdc4aac3 - coreclr_shutdown_2
  34:     0x7ffdfdb681a6 - <unknown>
  35:     0x7ffdfdbeeff7 - MetaDataGetDispenser
  36:     0x7ffdfdbeee76 - MetaDataGetDispenser
  37:     0x7ffdfdbeed25 - MetaDataGetDispenser
  38:     0x7ffdfdbeeae6 - MetaDataGetDispenser
  39:     0x7ffdfdc05dd2 - coreclr_execute_assembly
  40:     0x7ffe93b3971b - <unknown>
  41:     0x7ffe93b39a4c - <unknown>
  42:     0x7ffe93b3a3e7 - corehost_main
  43:     0x7ffe9fb6b77c - hostfxr_close
  44:     0x7ffe9fb6e3f7 - hostfxr_close
  45:     0x7ffe9fb7075f - hostfxr_close
  46:     0x7ffe9fb6ea53 - hostfxr_close
  47:     0x7ffe9fb6850b - hostfxr_main_startupinfo
  48:     0x7ff6c39d1eb8 - <unknown>
  49:     0x7ff6c39d222b - <unknown>
  50:     0x7ff6c39d36d8 - <unknown>
  51:     0x7ffebb5774b4 - BaseThreadInitThunk
  52:     0x7ffebbce26a1 - RtlUserThreadStart
Unhandled exception. Wasmtime.TrapException: called `Option::unwrap()` on a `None` value

I can reproduce the error, using the following configuration:

• Create a C# application (.NET 6.0) with "dotnet new console", containing a project reference to Wasmtime.Dotnet from commit https://github.com/bytecodealliance/wasmtime-dotnet/commit/415438c88eb9c3b8d52de924020ce21630fe070b.
• In the Wasmtime.csproj, remove the code for downloading wasmtime, and instead download wasmtime-v3.0.0-x86_64-windows-c-api.zip , and use the wasmtime.dll from there.
• Use the following code in the C# application (Program.cs):

using Wasmtime;

using var engine = new Engine();
using var module = Module.FromBytes(engine, "main", File.ReadAllBytes(@"dotnet-codabix-wasm-build.wasm"));

using var linker = new Linker(engine);
using var store = new Store(engine);
linker.DefineWasi();
var instance = linker.Instantiate(store, module);

var run = instance.GetAction("_start")!;
run();

• Use the following WASM file (this is not actually a movie; I renamed the .wasm to .mov to be able to upload it):
  https://user-images.githubusercontent.com/13289184/203989968-4639d6d5-15c9-4e57-bf01-c2eccd756642.mov

When running the C# application, it should print the above error to the console.

I did not yet have a chance to try to reproduce it using a plain C application. Also, I did not manage to reproduce the access violation in the above C# application, as it seems a bit hard to reproduce, but I would assume it has the same cause as the above error.

Do you have any idea what could be causing this? Do you need any further information?

On a related note, I can also reproduce this error using the Wasmtime dev release from commit 28cf995fd3f9926a95036758c78390f54a0289ae, but it seems it needs much more time for compiling the module (18.6 seconds for the dev version, but only 2.8 seconds for the 3.0.0 version).

Thank you!

Wasmtime GitHub notifications bot (Nov 25 2022 at 13:08):

kpreisser edited issue #5325:

Hi,
we use Wasmtime 3.0.0 with wasmtime-dotnet in an application where we load a 8 MB .wasm file produced by the WASI SDK for .NET.

After instantiating the module and calling the exported _start function, we either get an access violation, or the following error is printed to the console and returned as trap (with RUST_BACKTRACE=full (this is on Windows 10 x64 (Build 19044)):

thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', crates\c-api\src\linker.rs:104:63
stack backtrace:
   0:     0x7ffdf2b36d42 - impl_new_epoch
   1:     0x7ffdf2b5283b - impl_new_epoch
   2:     0x7ffdf2b31f7a - impl_new_epoch
   3:     0x7ffdf2b39464 - impl_new_epoch
   4:     0x7ffdf2b3909a - impl_new_epoch
   5:     0x7ffdf2b39c51 - impl_new_epoch
   6:     0x7ffdf2b39b1a - impl_new_epoch
   7:     0x7ffdf2b3776f - impl_new_epoch
   8:     0x7ffdf2b39820 - impl_new_epoch
   9:     0x7ffdf2bf4a85 - _jit_debug_register_code
  10:     0x7ffdf2bf492c - _jit_debug_register_code
  11:     0x7ffdf2533d52 - wasm_foreign_delete
  12:     0x7ffdf259008d - wasm_globaltype_copy
  13:     0x7ffdf25b7cad - wasmtime_val_delete
  14:     0x7ffdf24edb09 - wasm_foreign_delete
  15:      0x1b7f0bfa26d - <unknown>
  16:      0x1b7f0bfa090 - <unknown>
  17:      0x1b7f0bf8501 - <unknown>
  18:      0x1b7f086102c - <unknown>
  19:      0x1b7f0c22bee - <unknown>
  20:      0x1b7f0c230eb - <unknown>
  21:     0x7ffdf2bb2c73 - _jit_debug_register_code
  22:     0x7ffdf25c2d74 - wasmtime_val_delete
  23:     0x7ffdf25d55f6 - wasm_tabletype_copy
  24:     0x7ffdf24f4ef7 - wasm_foreign_delete
  25:     0x7ffdf24f7de5 - wasm_foreign_delete
  26:     0x7ffdf25e3ed0 - wasmtime_func_call
  27:     0x7ffd9e0b0f8c - <unknown>
  28:     0x7ffd9e0b0c79 - <unknown>
  29:     0x7ffd9e0b08a3 - <unknown>
  30:     0x7ffd9e0b06b8 - <unknown>
  31:     0x7ffd9e0a553c - <unknown>
  32:     0x7ffd9e0a2eb1 - <unknown>
  33:     0x7ffdfdc4aac3 - coreclr_shutdown_2
  34:     0x7ffdfdb681a6 - <unknown>
  35:     0x7ffdfdbeeff7 - MetaDataGetDispenser
  36:     0x7ffdfdbeee76 - MetaDataGetDispenser
  37:     0x7ffdfdbeed25 - MetaDataGetDispenser
  38:     0x7ffdfdbeeae6 - MetaDataGetDispenser
  39:     0x7ffdfdc05dd2 - coreclr_execute_assembly
  40:     0x7ffe93b3971b - <unknown>
  41:     0x7ffe93b39a4c - <unknown>
  42:     0x7ffe93b3a3e7 - corehost_main
  43:     0x7ffe9fb6b77c - hostfxr_close
  44:     0x7ffe9fb6e3f7 - hostfxr_close
  45:     0x7ffe9fb7075f - hostfxr_close
  46:     0x7ffe9fb6ea53 - hostfxr_close
  47:     0x7ffe9fb6850b - hostfxr_main_startupinfo
  48:     0x7ff6c39d1eb8 - <unknown>
  49:     0x7ff6c39d222b - <unknown>
  50:     0x7ff6c39d36d8 - <unknown>
  51:     0x7ffebb5774b4 - BaseThreadInitThunk
  52:     0x7ffebbce26a1 - RtlUserThreadStart
Unhandled exception. Wasmtime.TrapException: called `Option::unwrap()` on a `None` value

I can reproduce the error, using the following configuration:

• Create a C# application (.NET 6.0) with "dotnet new console", containing a project reference to Wasmtime.Dotnet from commit https://github.com/bytecodealliance/wasmtime-dotnet/commit/415438c88eb9c3b8d52de924020ce21630fe070b.
• In the Wasmtime.csproj, remove the code for downloading wasmtime, and instead download wasmtime-v3.0.0-x86_64-windows-c-api.zip , and use the wasmtime.dll from there.
• Use the following code in the C# application (Program.cs):

using Wasmtime;

using var engine = new Engine();
using var module = Module.FromBytes(engine, "main", File.ReadAllBytes(@"dotnet-codabix-wasm-build.wasm"));

using var linker = new Linker(engine);
using var store = new Store(engine);
linker.DefineWasi();
var instance = linker.Instantiate(store, module);

var run = instance.GetAction("_start")!;
run();

• Use the following WASM file as dotnet-codabix-wasm-build.wasm (this is not actually a movie; I renamed the .wasm to .mov to be able to upload it):
  https://user-images.githubusercontent.com/13289184/203989968-4639d6d5-15c9-4e57-bf01-c2eccd756642.mov

When running the C# application, it should print the above error to the console.

I did not yet have a chance to try to reproduce it using a plain C application. Also, I did not manage to reproduce the access violation in the above C# application, as it seems a bit hard to reproduce, but I would assume it has the same cause as the above error.

Do you have any idea what could be causing this? Do you need any further information?

On a related note, I can also reproduce this error using the Wasmtime dev release from commit 28cf995fd3f9926a95036758c78390f54a0289ae, but it seems it needs much more time for compiling the module (18.6 seconds for the dev version, but only 2.8 seconds for the 3.0.0 version).

Thank you!

Wasmtime GitHub notifications bot (Nov 25 2022 at 13:10):

kpreisser commented on issue #5325:

When using a debug build of Wasmtime from commit 28cf995, I get the following backtrace:

thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', crates\c-api\src\linker.rs:104:80
stack backtrace:
   0:     0x7ffdceced9c2 - std::backtrace_rs::backtrace::dbghelp::trace
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library\std\src\..\..\backtrace\src\backtrace\dbghelp.rs:98
   1:     0x7ffdceced9c2 - std::backtrace_rs::backtrace::trace_unsynchronized
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library\std\src\..\..\backtrace\src\backtrace\mod.rs:66
   2:     0x7ffdceced9c2 - std::sys_common::backtrace::_print_fmt
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library\std\src\sys_common\backtrace.rs:66
   3:     0x7ffdceced9c2 - std::sys_common::backtrace::_print::impl$0::fmt
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library\std\src\sys_common\backtrace.rs:45
   4:     0x7ffdced0991b - core::fmt::write
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library\core\src\fmt\mod.rs:1202
   5:     0x7ffdcece87ea - std::io::Write::write_fmt<std::sys::windows::stdio::Stderr>
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library\std\src\io\mod.rs:1679
   6:     0x7ffdcecf0114 - std::sys_common::backtrace::_print
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library\std\src\sys_common\backtrace.rs:48
   7:     0x7ffdcecf0114 - std::sys_common::backtrace::print
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library\std\src\sys_common\backtrace.rs:35
   8:     0x7ffdcecf0114 - std::panicking::default_hook::closure$1
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library\std\src\panicking.rs:295
   9:     0x7ffdcecefd4a - std::panicking::default_hook
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library\std\src\panicking.rs:314
  10:     0x7ffdcecf0901 - std::panicking::rust_panic_with_hook
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library\std\src\panicking.rs:698
  11:     0x7ffdcecf07ca - std::panicking::begin_panic_handler::closure$0
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library\std\src\panicking.rs:586
  12:     0x7ffdcecee3ef - std::sys_common::backtrace::__rust_end_short_backtrace<std::panicking::begin_panic_handler::closure_env$0,never$>
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library\std\src\sys_common\backtrace.rs:138
  13:     0x7ffdcecf04d0 - std::panicking::begin_panic_handler
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library\std\src\panicking.rs:584
  14:     0x7ffdced6d005 - core::panicking::panic_fmt
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library\core\src\panicking.rs:142
  15:     0x7ffdced6ceac - core::panicking::panic
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120/library\core\src\panicking.rs:48
  16:     0x7ffdcd875c4a - enum2$<core::option::Option<ref_mut$<wasi_common::ctx::WasiCtx> > >::unwrap<ref_mut$<wasi_common::ctx::WasiCtx> >
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120\library\core\src\option.rs:775
  17:     0x7ffdcd7f924a - wasmtime::linker::wasmtime_linker_define_wasi::closure$0
                               at C:\Users\developer4\Desktop\WebAssembly-Tests\wasmtime\crates\c-api\src\linker.rs:104
  18:     0x7ffdcd7d2011 - wasmtime_wasi::sync::snapshots::preview_1::add_wasi_snapshot_preview1_to_linker::closure$3::async_block$0<wasmtime::store::StoreData,wasi_common::ctx::WasiCtx,wasmtime::linker::wasmtime_linker_define_wasi::closure_env$0>
                               at C:\Users\developer4\Desktop\WebAssembly-Tests\wasmtime\crates\wasi\src\lib.rs:61
  19:     0x7ffdcd77d2bf - core::future::from_generator::impl$1::poll<enum2$<wasmtime_wasi::sync::snapshots::preview_1::add_wasi_snapshot_preview1_to_linker::closure$3::async_block_env$0<wasmtime::store::StoreData,wasi_common::ctx::WasiCtx,wasmtime::linker::wasmtime_linker_define_w
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120\library\core\src\future\mod.rs:91
  20:     0x7ffdcd77227e - wiggle::run_in_dummy_executor<core::future::from_generator::GenFuture<enum2$<wasmtime_wasi::sync::snapshots::preview_1::add_wasi_snapshot_preview1_to_linker::closure$3::async_block_env$0<wasmtime::store::StoreData,wasi_common::ctx::WasiCtx,wasmtime::linke
                               at C:\Users\developer4\Desktop\WebAssembly-Tests\wasmtime\crates\wiggle\src\lib.rs:1039
  21:     0x7ffdcd7c1ffd - wasmtime_wasi::sync::snapshots::preview_1::add_wasi_snapshot_preview1_to_linker::closure$3<wasmtime::store::StoreData,wasi_common::ctx::WasiCtx,wasmtime::linker::wasmtime_linker_define_wasi::closure_env$0>
                               at C:\Users\developer4\Desktop\WebAssembly-Tests\wasmtime\crates\wasi\src\lib.rs:61
  22:     0x7ffdcd809570 - wasmtime::func::impl$52::into_func::wasm_to_host_shim::closure$0::closure$0<wasmtime::store::StoreData,wasmtime_wasi::sync::snapshots::preview_1::add_wasi_snapshot_preview1_to_linker::closure_env$3<wasmtime::store::StoreData,wasi_common::ctx::WasiCtx,wasm
                               at C:\Users\developer4\Desktop\WebAssembly-Tests\wasmtime\crates\wasmtime\src\func.rs:1917
  23:     0x7ffdcd97f60e - core::ops::function::FnOnce::call_once<wasmtime::func::impl$52::into_func::wasm_to_host_shim::closure$0::closure_env$0<wasmtime::store::StoreData,wasmtime_wasi::sync::snapshots::preview_1::add_wasi_snapshot_preview1_to_linker::closure_env$3<wasmtime::stor
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120\library\core\src\ops\function.rs:248
  24:     0x7ffdcd9cf499 - core::panic::unwind_safe::impl$23::call_once<enum2$<core::result::Result<i32,anyhow::Error> >,wasmtime::func::impl$52::into_func::wasm_to_host_shim::closure$0::closure_env$0<wasmtime::store::StoreData,wasmtime_wasi::sync::snapshots::preview_1::add_wasi_sn
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120\library\core\src\panic\unwind_safe.rs:271
  25:     0x7ffdcd9e2021 - std::panicking::try::do_call<core::panic::unwind_safe::AssertUnwindSafe<wasmtime::func::impl$52::into_func::wasm_to_host_shim::closure$0::closure_env$0<wasmtime::store::StoreData,wasmtime_wasi::sync::snapshots::preview_1::add_wasi_snapshot_preview1_to_lin
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120\library\std\src\panicking.rs:492
  26:     0x7ffdcd9eae83 - std::panicking::try::do_catch<core::panic::unwind_safe::AssertUnwindSafe<wasmtime::trampoline::func::stub_fn::closure_env$0<wasmtime::func::impl$6::new_unchecked::closure_env$0<tuple$<>,wasmtime::func::impl$0::new::closure_env$0<tuple$<>,wasmtime::store::
  27:     0x7ffdcd9d82db - std::panicking::try<enum2$<core::result::Result<i32,anyhow::Error> >,core::panic::unwind_safe::AssertUnwindSafe<wasmtime::func::impl$52::into_func::wasm_to_host_shim::closure$0::closure_env$0<wasmtime::store::StoreData,wasmtime_wasi::sync::snapshots::prev
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120\library\std\src\panicking.rs:456
  28:     0x7ffdcd847d39 - std::panic::catch_unwind<core::panic::unwind_safe::AssertUnwindSafe<wasmtime::func::impl$52::into_func::wasm_to_host_shim::closure$0::closure_env$0<wasmtime::store::StoreData,wasmtime_wasi::sync::snapshots::preview_1::add_wasi_snapshot_preview1_to_linker:
                               at /rustc/897e37553bba8b42751c67658967889d11ecd120\library\std\src\panic.rs:137
  29:     0x7ffdcd800f20 - wasmtime::func::impl$52::into_func::wasm_to_host_shim::closure$0<wasmtime::store::StoreData,wasmtime_wasi::sync::snapshots::preview_1::add_wasi_snapshot_preview1_to_linker::closure_env$3<wasmtime::store::StoreData,wasi_common::ctx::WasiCtx,wasmtime::linke
                               at C:\Users\developer4\Desktop\WebAssembly-Tests\wasmtime\crates\wasmtime\src\func.rs:1912
  30:     0x7ffdcd834595 - wasmtime::func::Caller<wasmtime::store::StoreData>::with<wasmtime::store::StoreData,enum2$<wasmtime::func::impl$52::into_func::wasm_to_host_shim::CallResult<i32> >,wasmtime::func::impl$52::into_func::wasm_to_host_shim::closure_env$0<wasmtime::store::Store
                               at C:\Users\developer4\Desktop\WebAssembly-Tests\wasmtime\crates\wasmtime\src\func.rs:1714
  31:     0x7ffdcd7ff015 - wasmtime::func::impl$52::into_func::wasm_to_host_shim<wasmtime::store::StoreData,wasmtime_wasi::sync::snapshots::preview_1::add_wasi_snapshot_preview1_to_linker::closure_env$3<wasmtime::store::StoreData,wasi_common::ctx::WasiCtx,wasmtime::linker::wasmtime
                               at C:\Users\developer4\Desktop\WebAssembly-Tests\wasmtime\crates\wasmtime\src\func.rs:1901
  32:      0x1226a717e4e - <unknown>
  33:      0x1226a717ba1 - <unknown>
  34:      0x1226a714e81 - <unknown>
  35:      0x12269bb102c - <unknown>
  36:      0x1226a74f22e - <unknown>
  37:      0x1226a74f72b - <unknown>
  38:     0x7ffdcd8394fc - wasmtime::func::impl$0::call_unchecked_raw::closure$0<wasmtime::store::StoreData>
                               at C:\Users\developer4\Desktop\WebAssembly-Tests\wasmtime\crates\wasmtime\src\func.rs:900
  39:     0x7ffdcd867a3d - wasmtime_runtime::traphandlers::catch_traps::call_closure<wasmtime::func::impl$0::call_
[message truncated]

Wasmtime GitHub notifications bot (Nov 25 2022 at 13:16):

kpreisser edited issue #5325:

Hi,
we use Wasmtime 3.0.0 with wasmtime-dotnet in an application where we load a 8 MB .wasm file produced by the WASI SDK for .NET.

After instantiating the module and calling the exported _start function, we either get an access violation, or the following error is printed to the console and returned as trap (with RUST_BACKTRACE=full (this is on Windows 10 x64 (Build 19044)):

thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', crates\c-api\src\linker.rs:104:63
stack backtrace:
   0:     0x7ffdf2b36d42 - impl_new_epoch
   1:     0x7ffdf2b5283b - impl_new_epoch
   2:     0x7ffdf2b31f7a - impl_new_epoch
   3:     0x7ffdf2b39464 - impl_new_epoch
   4:     0x7ffdf2b3909a - impl_new_epoch
   5:     0x7ffdf2b39c51 - impl_new_epoch
   6:     0x7ffdf2b39b1a - impl_new_epoch
   7:     0x7ffdf2b3776f - impl_new_epoch
   8:     0x7ffdf2b39820 - impl_new_epoch
   9:     0x7ffdf2bf4a85 - _jit_debug_register_code
  10:     0x7ffdf2bf492c - _jit_debug_register_code
  11:     0x7ffdf2533d52 - wasm_foreign_delete
  12:     0x7ffdf259008d - wasm_globaltype_copy
  13:     0x7ffdf25b7cad - wasmtime_val_delete
  14:     0x7ffdf24edb09 - wasm_foreign_delete
  15:      0x1b7f0bfa26d - <unknown>
  16:      0x1b7f0bfa090 - <unknown>
  17:      0x1b7f0bf8501 - <unknown>
  18:      0x1b7f086102c - <unknown>
  19:      0x1b7f0c22bee - <unknown>
  20:      0x1b7f0c230eb - <unknown>
  21:     0x7ffdf2bb2c73 - _jit_debug_register_code
  22:     0x7ffdf25c2d74 - wasmtime_val_delete
  23:     0x7ffdf25d55f6 - wasm_tabletype_copy
  24:     0x7ffdf24f4ef7 - wasm_foreign_delete
  25:     0x7ffdf24f7de5 - wasm_foreign_delete
  26:     0x7ffdf25e3ed0 - wasmtime_func_call
  27:     0x7ffd9e0b0f8c - <unknown>
  28:     0x7ffd9e0b0c79 - <unknown>
  29:     0x7ffd9e0b08a3 - <unknown>
  30:     0x7ffd9e0b06b8 - <unknown>
  31:     0x7ffd9e0a553c - <unknown>
  32:     0x7ffd9e0a2eb1 - <unknown>
  33:     0x7ffdfdc4aac3 - coreclr_shutdown_2
  34:     0x7ffdfdb681a6 - <unknown>
  35:     0x7ffdfdbeeff7 - MetaDataGetDispenser
  36:     0x7ffdfdbeee76 - MetaDataGetDispenser
  37:     0x7ffdfdbeed25 - MetaDataGetDispenser
  38:     0x7ffdfdbeeae6 - MetaDataGetDispenser
  39:     0x7ffdfdc05dd2 - coreclr_execute_assembly
  40:     0x7ffe93b3971b - <unknown>
  41:     0x7ffe93b39a4c - <unknown>
  42:     0x7ffe93b3a3e7 - corehost_main
  43:     0x7ffe9fb6b77c - hostfxr_close
  44:     0x7ffe9fb6e3f7 - hostfxr_close
  45:     0x7ffe9fb7075f - hostfxr_close
  46:     0x7ffe9fb6ea53 - hostfxr_close
  47:     0x7ffe9fb6850b - hostfxr_main_startupinfo
  48:     0x7ff6c39d1eb8 - <unknown>
  49:     0x7ff6c39d222b - <unknown>
  50:     0x7ff6c39d36d8 - <unknown>
  51:     0x7ffebb5774b4 - BaseThreadInitThunk
  52:     0x7ffebbce26a1 - RtlUserThreadStart
Unhandled exception. Wasmtime.TrapException: called `Option::unwrap()` on a `None` value

I can reproduce the error, using the following configuration:

• Create a C# application (.NET 6.0) with "dotnet new console", containing a project reference to Wasmtime.Dotnet from commit https://github.com/bytecodealliance/wasmtime-dotnet/commit/415438c88eb9c3b8d52de924020ce21630fe070b.
• In the Wasmtime.csproj, remove the code for downloading wasmtime, and instead download wasmtime-v3.0.0-x86_64-windows-c-api.zip , and use the wasmtime.dll from there.
• Use the following code in the C# application (Program.cs):

using Wasmtime;

using var engine = new Engine();
using var module = Module.FromBytes(engine, "main", File.ReadAllBytes(@"dotnet-codabix-wasm-build.wasm"));

using var linker = new Linker(engine);
using var store = new Store(engine);
linker.DefineWasi();
var instance = linker.Instantiate(store, module);

var run = instance.GetAction("_start")!;
run();

• Download the following .Zip file and extract dotnet-codabix-wasm-build.wasmI from it (this is not actually a movie; I renamed the .zip zo .mov to be able to upload it):
  https://user-images.githubusercontent.com/13289184/203989968-4639d6d5-15c9-4e57-bf01-c2eccd756642.mov

When running the C# application, it should print the above error to the console.

I did not yet have a chance to try to reproduce it using a plain C application. Also, I did not manage to reproduce the access violation in the above C# application, as it seems a bit hard to reproduce, but I would assume it has the same cause as the above error.

Do you have any idea what could be causing this? Do you need any further information?

On a related note, I can also reproduce this error using the Wasmtime dev release from commit 28cf995fd3f9926a95036758c78390f54a0289ae, but it seems it needs much more time for compiling the module (18.6 seconds for the dev version, but only 2.8 seconds for the 3.0.0 version).

Thank you!

Wasmtime GitHub notifications bot (Nov 25 2022 at 13:16):

kpreisser edited issue #5325:

Hi,
we use Wasmtime 3.0.0 with wasmtime-dotnet in an application where we load a 8 MB .wasm file produced by the WASI SDK for .NET.

After instantiating the module and calling the exported _start function, we either get an access violation, or the following error is printed to the console and returned as trap (with RUST_BACKTRACE=full (this is on Windows 10 x64 (Build 19044)):

thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', crates\c-api\src\linker.rs:104:63
stack backtrace:
   0:     0x7ffdf2b36d42 - impl_new_epoch
   1:     0x7ffdf2b5283b - impl_new_epoch
   2:     0x7ffdf2b31f7a - impl_new_epoch
   3:     0x7ffdf2b39464 - impl_new_epoch
   4:     0x7ffdf2b3909a - impl_new_epoch
   5:     0x7ffdf2b39c51 - impl_new_epoch
   6:     0x7ffdf2b39b1a - impl_new_epoch
   7:     0x7ffdf2b3776f - impl_new_epoch
   8:     0x7ffdf2b39820 - impl_new_epoch
   9:     0x7ffdf2bf4a85 - _jit_debug_register_code
  10:     0x7ffdf2bf492c - _jit_debug_register_code
  11:     0x7ffdf2533d52 - wasm_foreign_delete
  12:     0x7ffdf259008d - wasm_globaltype_copy
  13:     0x7ffdf25b7cad - wasmtime_val_delete
  14:     0x7ffdf24edb09 - wasm_foreign_delete
  15:      0x1b7f0bfa26d - <unknown>
  16:      0x1b7f0bfa090 - <unknown>
  17:      0x1b7f0bf8501 - <unknown>
  18:      0x1b7f086102c - <unknown>
  19:      0x1b7f0c22bee - <unknown>
  20:      0x1b7f0c230eb - <unknown>
  21:     0x7ffdf2bb2c73 - _jit_debug_register_code
  22:     0x7ffdf25c2d74 - wasmtime_val_delete
  23:     0x7ffdf25d55f6 - wasm_tabletype_copy
  24:     0x7ffdf24f4ef7 - wasm_foreign_delete
  25:     0x7ffdf24f7de5 - wasm_foreign_delete
  26:     0x7ffdf25e3ed0 - wasmtime_func_call
  27:     0x7ffd9e0b0f8c - <unknown>
  28:     0x7ffd9e0b0c79 - <unknown>
  29:     0x7ffd9e0b08a3 - <unknown>
  30:     0x7ffd9e0b06b8 - <unknown>
  31:     0x7ffd9e0a553c - <unknown>
  32:     0x7ffd9e0a2eb1 - <unknown>
  33:     0x7ffdfdc4aac3 - coreclr_shutdown_2
  34:     0x7ffdfdb681a6 - <unknown>
  35:     0x7ffdfdbeeff7 - MetaDataGetDispenser
  36:     0x7ffdfdbeee76 - MetaDataGetDispenser
  37:     0x7ffdfdbeed25 - MetaDataGetDispenser
  38:     0x7ffdfdbeeae6 - MetaDataGetDispenser
  39:     0x7ffdfdc05dd2 - coreclr_execute_assembly
  40:     0x7ffe93b3971b - <unknown>
  41:     0x7ffe93b39a4c - <unknown>
  42:     0x7ffe93b3a3e7 - corehost_main
  43:     0x7ffe9fb6b77c - hostfxr_close
  44:     0x7ffe9fb6e3f7 - hostfxr_close
  45:     0x7ffe9fb7075f - hostfxr_close
  46:     0x7ffe9fb6ea53 - hostfxr_close
  47:     0x7ffe9fb6850b - hostfxr_main_startupinfo
  48:     0x7ff6c39d1eb8 - <unknown>
  49:     0x7ff6c39d222b - <unknown>
  50:     0x7ff6c39d36d8 - <unknown>
  51:     0x7ffebb5774b4 - BaseThreadInitThunk
  52:     0x7ffebbce26a1 - RtlUserThreadStart
Unhandled exception. Wasmtime.TrapException: called `Option::unwrap()` on a `None` value

I can reproduce the error, using the following configuration:

• Create a C# application (.NET 6.0) with "dotnet new console", containing a project reference to Wasmtime.Dotnet from commit https://github.com/bytecodealliance/wasmtime-dotnet/commit/415438c88eb9c3b8d52de924020ce21630fe070b.
• In the Wasmtime.csproj, remove the code for downloading wasmtime, and instead download wasmtime-v3.0.0-x86_64-windows-c-api.zip , and use the wasmtime.dll from there.
• Use the following code in the C# application (Program.cs):

using Wasmtime;

using var engine = new Engine();
using var module = Module.FromBytes(engine, "main", File.ReadAllBytes(@"dotnet-codabix-wasm-build.wasm"));

using var linker = new Linker(engine);
using var store = new Store(engine);
linker.DefineWasi();
var instance = linker.Instantiate(store, module);

var run = instance.GetAction("_start")!;
run();

• Download the following .Zip file and extract dotnet-codabix-wasm-build.wasm from it (this is not actually a movie; I renamed the .zip zo .mov to be able to upload it):
  https://user-images.githubusercontent.com/13289184/203989968-4639d6d5-15c9-4e57-bf01-c2eccd756642.mov

When running the C# application, it should print the above error to the console.

I did not yet have a chance to try to reproduce it using a plain C application. Also, I did not manage to reproduce the access violation in the above C# application, as it seems a bit hard to reproduce, but I would assume it has the same cause as the above error.

Do you have any idea what could be causing this? Do you need any further information?

On a related note, I can also reproduce this error using the Wasmtime dev release from commit 28cf995fd3f9926a95036758c78390f54a0289ae, but it seems it needs much more time for compiling the module (18.6 seconds for the dev version, but only 2.8 seconds for the 3.0.0 version).

Thank you!

Wasmtime GitHub notifications bot (Nov 25 2022 at 13:18):

kpreisser edited issue #5325:

Hi,
we use Wasmtime 3.0.0 with wasmtime-dotnet in an application where we load a 8 MB .wasm file produced by the WASI SDK for .NET.

After instantiating the module and calling the exported _start function, we either get an access violation, or the following error is printed to the console and returned as trap (with RUST_BACKTRACE=full (this is on Windows 10 x64 (Build 19044)):

thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', crates\c-api\src\linker.rs:104:63
stack backtrace:
   0:     0x7ffdf2b36d42 - impl_new_epoch
   1:     0x7ffdf2b5283b - impl_new_epoch
   2:     0x7ffdf2b31f7a - impl_new_epoch
   3:     0x7ffdf2b39464 - impl_new_epoch
   4:     0x7ffdf2b3909a - impl_new_epoch
   5:     0x7ffdf2b39c51 - impl_new_epoch
   6:     0x7ffdf2b39b1a - impl_new_epoch
   7:     0x7ffdf2b3776f - impl_new_epoch
   8:     0x7ffdf2b39820 - impl_new_epoch
   9:     0x7ffdf2bf4a85 - _jit_debug_register_code
  10:     0x7ffdf2bf492c - _jit_debug_register_code
  11:     0x7ffdf2533d52 - wasm_foreign_delete
  12:     0x7ffdf259008d - wasm_globaltype_copy
  13:     0x7ffdf25b7cad - wasmtime_val_delete
  14:     0x7ffdf24edb09 - wasm_foreign_delete
  15:      0x1b7f0bfa26d - <unknown>
  16:      0x1b7f0bfa090 - <unknown>
  17:      0x1b7f0bf8501 - <unknown>
  18:      0x1b7f086102c - <unknown>
  19:      0x1b7f0c22bee - <unknown>
  20:      0x1b7f0c230eb - <unknown>
  21:     0x7ffdf2bb2c73 - _jit_debug_register_code
  22:     0x7ffdf25c2d74 - wasmtime_val_delete
  23:     0x7ffdf25d55f6 - wasm_tabletype_copy
  24:     0x7ffdf24f4ef7 - wasm_foreign_delete
  25:     0x7ffdf24f7de5 - wasm_foreign_delete
  26:     0x7ffdf25e3ed0 - wasmtime_func_call
  27:     0x7ffd9e0b0f8c - <unknown>
  28:     0x7ffd9e0b0c79 - <unknown>
  29:     0x7ffd9e0b08a3 - <unknown>
  30:     0x7ffd9e0b06b8 - <unknown>
  31:     0x7ffd9e0a553c - <unknown>
  32:     0x7ffd9e0a2eb1 - <unknown>
  33:     0x7ffdfdc4aac3 - coreclr_shutdown_2
  34:     0x7ffdfdb681a6 - <unknown>
  35:     0x7ffdfdbeeff7 - MetaDataGetDispenser
  36:     0x7ffdfdbeee76 - MetaDataGetDispenser
  37:     0x7ffdfdbeed25 - MetaDataGetDispenser
  38:     0x7ffdfdbeeae6 - MetaDataGetDispenser
  39:     0x7ffdfdc05dd2 - coreclr_execute_assembly
  40:     0x7ffe93b3971b - <unknown>
  41:     0x7ffe93b39a4c - <unknown>
  42:     0x7ffe93b3a3e7 - corehost_main
  43:     0x7ffe9fb6b77c - hostfxr_close
  44:     0x7ffe9fb6e3f7 - hostfxr_close
  45:     0x7ffe9fb7075f - hostfxr_close
  46:     0x7ffe9fb6ea53 - hostfxr_close
  47:     0x7ffe9fb6850b - hostfxr_main_startupinfo
  48:     0x7ff6c39d1eb8 - <unknown>
  49:     0x7ff6c39d222b - <unknown>
  50:     0x7ff6c39d36d8 - <unknown>
  51:     0x7ffebb5774b4 - BaseThreadInitThunk
  52:     0x7ffebbce26a1 - RtlUserThreadStart
Unhandled exception. Wasmtime.TrapException: called `Option::unwrap()` on a `None` value

I can reproduce the error, using the following configuration:

• Create a C# application (.NET 6.0) with "dotnet new console", containing a project reference to Wasmtime.Dotnet from commit https://github.com/bytecodealliance/wasmtime-dotnet/commit/415438c88eb9c3b8d52de924020ce21630fe070b.
• In the Wasmtime.csproj, remove the code for downloading wasmtime, and instead download wasmtime-v3.0.0-x86_64-windows-c-api.zip , and use the wasmtime.dll from there.
• Use the following code in the C# application (Program.cs):

using Wasmtime;

using var engine = new Engine();
using var module = Module.FromBytes(engine, "main", File.ReadAllBytes(@"dotnet-codabix-wasm-build.wasm"));

using var linker = new Linker(engine);
using var store = new Store(engine);
linker.DefineWasi();
var instance = linker.Instantiate(store, module);

var run = instance.GetAction("_start")!;
run();

• Download the following .Zip file and extract dotnet-codabix-wasm-build.wasm from it (this is not actually a movie; I renamed the .zip to .mov to be able to upload it):
  https://user-images.githubusercontent.com/13289184/203989968-4639d6d5-15c9-4e57-bf01-c2eccd756642.mov

When running the C# application, it should print the above error to the console.

I did not yet have a chance to try to reproduce it using a plain C application. Also, I did not manage to reproduce the access violation in the above C# application, as it seems a bit hard to reproduce, but I would assume it has the same cause as the above error.

Do you have any idea what could be causing this? Do you need any further information?

On a related note, I can also reproduce this error using the Wasmtime dev release from commit 28cf995fd3f9926a95036758c78390f54a0289ae, but it seems it needs much more time for compiling the module (18.6 seconds for the dev version, but only 2.8 seconds for the 3.0.0 version).

Thank you!

Wasmtime GitHub notifications bot (Nov 25 2022 at 14:28):

kpreisser edited issue #5325:

Hi,
we use Wasmtime 3.0.0 with wasmtime-dotnet in an application where we load a 8 MB .wasm file produced by the WASI SDK for .NET.

After instantiating the module and calling the exported _start function, we either get an access violation, or the following error is printed to the console and returned as trap (with RUST_BACKTRACE=full (this is on Windows 10 x64 (Build 19044)):

thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', crates\c-api\src\linker.rs:104:63
stack backtrace:
   0:     0x7ffdf2b36d42 - impl_new_epoch
   1:     0x7ffdf2b5283b - impl_new_epoch
   2:     0x7ffdf2b31f7a - impl_new_epoch
   3:     0x7ffdf2b39464 - impl_new_epoch
   4:     0x7ffdf2b3909a - impl_new_epoch
   5:     0x7ffdf2b39c51 - impl_new_epoch
   6:     0x7ffdf2b39b1a - impl_new_epoch
   7:     0x7ffdf2b3776f - impl_new_epoch
   8:     0x7ffdf2b39820 - impl_new_epoch
   9:     0x7ffdf2bf4a85 - _jit_debug_register_code
  10:     0x7ffdf2bf492c - _jit_debug_register_code
  11:     0x7ffdf2533d52 - wasm_foreign_delete
  12:     0x7ffdf259008d - wasm_globaltype_copy
  13:     0x7ffdf25b7cad - wasmtime_val_delete
  14:     0x7ffdf24edb09 - wasm_foreign_delete
  15:      0x1b7f0bfa26d - <unknown>
  16:      0x1b7f0bfa090 - <unknown>
  17:      0x1b7f0bf8501 - <unknown>
  18:      0x1b7f086102c - <unknown>
  19:      0x1b7f0c22bee - <unknown>
  20:      0x1b7f0c230eb - <unknown>
  21:     0x7ffdf2bb2c73 - _jit_debug_register_code
  22:     0x7ffdf25c2d74 - wasmtime_val_delete
  23:     0x7ffdf25d55f6 - wasm_tabletype_copy
  24:     0x7ffdf24f4ef7 - wasm_foreign_delete
  25:     0x7ffdf24f7de5 - wasm_foreign_delete
  26:     0x7ffdf25e3ed0 - wasmtime_func_call
  27:     0x7ffd9e0b0f8c - <unknown>
  28:     0x7ffd9e0b0c79 - <unknown>
  29:     0x7ffd9e0b08a3 - <unknown>
  30:     0x7ffd9e0b06b8 - <unknown>
  31:     0x7ffd9e0a553c - <unknown>
  32:     0x7ffd9e0a2eb1 - <unknown>
  33:     0x7ffdfdc4aac3 - coreclr_shutdown_2
  34:     0x7ffdfdb681a6 - <unknown>
  35:     0x7ffdfdbeeff7 - MetaDataGetDispenser
  36:     0x7ffdfdbeee76 - MetaDataGetDispenser
  37:     0x7ffdfdbeed25 - MetaDataGetDispenser
  38:     0x7ffdfdbeeae6 - MetaDataGetDispenser
  39:     0x7ffdfdc05dd2 - coreclr_execute_assembly
  40:     0x7ffe93b3971b - <unknown>
  41:     0x7ffe93b39a4c - <unknown>
  42:     0x7ffe93b3a3e7 - corehost_main
  43:     0x7ffe9fb6b77c - hostfxr_close
  44:     0x7ffe9fb6e3f7 - hostfxr_close
  45:     0x7ffe9fb7075f - hostfxr_close
  46:     0x7ffe9fb6ea53 - hostfxr_close
  47:     0x7ffe9fb6850b - hostfxr_main_startupinfo
  48:     0x7ff6c39d1eb8 - <unknown>
  49:     0x7ff6c39d222b - <unknown>
  50:     0x7ff6c39d36d8 - <unknown>
  51:     0x7ffebb5774b4 - BaseThreadInitThunk
  52:     0x7ffebbce26a1 - RtlUserThreadStart
Unhandled exception. Wasmtime.TrapException: called `Option::unwrap()` on a `None` value

I can reproduce the error, using the following configuration:

• Create a C# application (.NET 6.0) with "dotnet new console", containing a project reference to Wasmtime.Dotnet from commit https://github.com/bytecodealliance/wasmtime-dotnet/commit/415438c88eb9c3b8d52de924020ce21630fe070b.
• In the Wasmtime.csproj, remove the code for downloading wasmtime, and instead download wasmtime-v3.0.0-x86_64-windows-c-api.zip , and use the wasmtime.dll from there.
• Use the following code in the C# application (Program.cs):

using Wasmtime;

using var engine = new Engine();
using var module = Module.FromBytes(engine, "main", File.ReadAllBytes(@"dotnet-codabix-wasm-build.wasm"));

using var linker = new Linker(engine);
using var store = new Store(engine);
linker.DefineWasi();
var instance = linker.Instantiate(store, module);

var run = instance.GetAction("_start")!;
run();

• Download the following .Zip file and extract dotnet-codabix-wasm-build.wasm from it (this is not actually a movie; I renamed the .zip to .mov to be able to upload it):
  https://user-images.githubusercontent.com/13289184/203989968-4639d6d5-15c9-4e57-bf01-c2eccd756642.mov

When running the C# application, it should print the above error to the console.

I did not yet have a chance to try to reproduce it using a plain C application. Also, I did not manage to reproduce the access violation in the above C# application, as it seems a bit hard to reproduce, but I would assume it has the same cause as the above error.

Do you have any idea what could be causing this? Do you need any further information?

On a related note, I can also reproduce this error using the Wasmtime dev release from commit 28cf995fd3f9926a95036758c78390f54a0289ae, but it seems it needs much more time for compiling the module (18.6 seconds for the dev version, but only 2.8 seconds for the 3.0.0 version).

Thank you!

Wasmtime GitHub notifications bot (Nov 25 2022 at 15:09):

bjorn3 commented on issue #5325:

I think you need to call the C# equivalent of wasmtime_context_set_wasi on the store.

Wasmtime GitHub notifications bot (Nov 25 2022 at 15:15):

kpreisser commented on issue #5325:

Thanks! You are right, this fixes the error. Unfortunately, this doesn't fix the access violation in our other application (where the call to store.SetWasiConfiguration() already occurs), so this actually seems to be a different error.

I will continue to try to reproduce that and then open a new issue.

Wasmtime GitHub notifications bot (Nov 25 2022 at 15:15):

kpreisser closed issue #5325:

Hi,
we use Wasmtime 3.0.0 with wasmtime-dotnet in an application where we load a 8 MB .wasm file produced by the WASI SDK for .NET.

After instantiating the module and calling the exported _start function, we either get an access violation, or the following error is printed to the console and returned as trap (with RUST_BACKTRACE=full (this is on Windows 10 x64 (Build 19044)):

thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', crates\c-api\src\linker.rs:104:63
stack backtrace:
   0:     0x7ffdf2b36d42 - impl_new_epoch
   1:     0x7ffdf2b5283b - impl_new_epoch
   2:     0x7ffdf2b31f7a - impl_new_epoch
   3:     0x7ffdf2b39464 - impl_new_epoch
   4:     0x7ffdf2b3909a - impl_new_epoch
   5:     0x7ffdf2b39c51 - impl_new_epoch
   6:     0x7ffdf2b39b1a - impl_new_epoch
   7:     0x7ffdf2b3776f - impl_new_epoch
   8:     0x7ffdf2b39820 - impl_new_epoch
   9:     0x7ffdf2bf4a85 - _jit_debug_register_code
  10:     0x7ffdf2bf492c - _jit_debug_register_code
  11:     0x7ffdf2533d52 - wasm_foreign_delete
  12:     0x7ffdf259008d - wasm_globaltype_copy
  13:     0x7ffdf25b7cad - wasmtime_val_delete
  14:     0x7ffdf24edb09 - wasm_foreign_delete
  15:      0x1b7f0bfa26d - <unknown>
  16:      0x1b7f0bfa090 - <unknown>
  17:      0x1b7f0bf8501 - <unknown>
  18:      0x1b7f086102c - <unknown>
  19:      0x1b7f0c22bee - <unknown>
  20:      0x1b7f0c230eb - <unknown>
  21:     0x7ffdf2bb2c73 - _jit_debug_register_code
  22:     0x7ffdf25c2d74 - wasmtime_val_delete
  23:     0x7ffdf25d55f6 - wasm_tabletype_copy
  24:     0x7ffdf24f4ef7 - wasm_foreign_delete
  25:     0x7ffdf24f7de5 - wasm_foreign_delete
  26:     0x7ffdf25e3ed0 - wasmtime_func_call
  27:     0x7ffd9e0b0f8c - <unknown>
  28:     0x7ffd9e0b0c79 - <unknown>
  29:     0x7ffd9e0b08a3 - <unknown>
  30:     0x7ffd9e0b06b8 - <unknown>
  31:     0x7ffd9e0a553c - <unknown>
  32:     0x7ffd9e0a2eb1 - <unknown>
  33:     0x7ffdfdc4aac3 - coreclr_shutdown_2
  34:     0x7ffdfdb681a6 - <unknown>
  35:     0x7ffdfdbeeff7 - MetaDataGetDispenser
  36:     0x7ffdfdbeee76 - MetaDataGetDispenser
  37:     0x7ffdfdbeed25 - MetaDataGetDispenser
  38:     0x7ffdfdbeeae6 - MetaDataGetDispenser
  39:     0x7ffdfdc05dd2 - coreclr_execute_assembly
  40:     0x7ffe93b3971b - <unknown>
  41:     0x7ffe93b39a4c - <unknown>
  42:     0x7ffe93b3a3e7 - corehost_main
  43:     0x7ffe9fb6b77c - hostfxr_close
  44:     0x7ffe9fb6e3f7 - hostfxr_close
  45:     0x7ffe9fb7075f - hostfxr_close
  46:     0x7ffe9fb6ea53 - hostfxr_close
  47:     0x7ffe9fb6850b - hostfxr_main_startupinfo
  48:     0x7ff6c39d1eb8 - <unknown>
  49:     0x7ff6c39d222b - <unknown>
  50:     0x7ff6c39d36d8 - <unknown>
  51:     0x7ffebb5774b4 - BaseThreadInitThunk
  52:     0x7ffebbce26a1 - RtlUserThreadStart
Unhandled exception. Wasmtime.TrapException: called `Option::unwrap()` on a `None` value

I can reproduce the error, using the following configuration:

• Create a C# application (.NET 6.0) with "dotnet new console", containing a project reference to Wasmtime.Dotnet from commit https://github.com/bytecodealliance/wasmtime-dotnet/commit/415438c88eb9c3b8d52de924020ce21630fe070b.
• In the Wasmtime.csproj, remove the code for downloading wasmtime, and instead download wasmtime-v3.0.0-x86_64-windows-c-api.zip , and use the wasmtime.dll from there.
• Use the following code in the C# application (Program.cs):

using Wasmtime;

using var engine = new Engine();
using var module = Module.FromBytes(engine, "main", File.ReadAllBytes(@"dotnet-codabix-wasm-build.wasm"));

using var linker = new Linker(engine);
using var store = new Store(engine);
linker.DefineWasi();
var instance = linker.Instantiate(store, module);

var run = instance.GetAction("_start")!;
run();

• Download the following .Zip file and extract dotnet-codabix-wasm-build.wasm from it (this is not actually a movie; I renamed the .zip to .mov to be able to upload it):
  https://user-images.githubusercontent.com/13289184/203989968-4639d6d5-15c9-4e57-bf01-c2eccd756642.mov

When running the C# application, it should print the above error to the console.

I did not yet have a chance to try to reproduce it using a plain C application. Also, I did not manage to reproduce the access violation in the above C# application, as it seems a bit hard to reproduce, but I would assume it has the same cause as the above error.

Do you have any idea what could be causing this? Do you need any further information?

On a related note, I can also reproduce this error using the Wasmtime dev release from commit 28cf995fd3f9926a95036758c78390f54a0289ae, but it seems it needs much more time for compiling the module (18.6 seconds for the dev version, but only 2.8 seconds for the 3.0.0 version).

Thank you!

Wasmtime GitHub notifications bot (Nov 25 2022 at 15:38):

kpreisser edited a comment on issue #5325:

Thanks! You are right, this fixes the error. Unfortunately, this doesn't fix the access violation in our other application (where the call to store.SetWasiConfiguration() already occurs), so this actually seems to be a different error.

I will continue to try to reproduce that and then open a new issue if needed.

Last updated: Nov 22 2024 at 16:03 UTC