Closed kpreisser closed 4 days ago
Issue is still occuring. How is WASI going to be useful if this happens?
It seems this has been resolved in .NET 8.0 when using the wasi-wasm
workload/RID (which obsoletes the Wasi.Sdk
): Manually or automatically invoking GC no longer crashes the wasm module and correctly releases the memory, so I think this issue can be closed.
However, I noticed that even though the memory is freed, finalizers are not executed (at least when not using the WASI threads feature).
Hi there!
As noted in https://github.com/SteveSandersonMS/dotnet-wasi-sdk/issues/50#issuecomment-1381490203, when building a .NET application that uses
Wasi.Sdk 0.1.3-preview.10012
to a.wasm
file and running it withWasmtime
, the Wasm crashes with a failed assertion as soon as the Garbage Collector is invoked (either manually withGC.Collect()
, or automatically by allocating (and throwing away) a large number of objects).You can reproduce it as follows:
Wasi.Sdk
:Program.cs
as follows:dotnet build
wasmtime 6.0.0
and run:wasmtime bin/Debug/net7.0/MyFirstWasiApp.wasm
Expected behavior: Prints
GC successful.
and returns a0
exit code.Actual Behavior: Prints the following assertion error, and returns an
1
exit code:Is there any way to fix this issue? This appears to be currently the only issue that prevents us from using
Wasi.Sdk
in a productive way, in order to allow customers to create .NET plugins for our middleware application that usesWasmtime
to run these plugins in a sandboxed environment, using a defined API (functions that the WASM can import and may export).Thank you!