Invoking GC crashes the WASM (Assertion failed)

[kpreisser]

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 with Wasmtime, the Wasm crashes with a failed assertion as soon as the Garbage Collector is invoked (either manually with GC.Collect(), or automatically by allocating (and throwing away) a large number of objects).

You can reproduce it as follows:

• Create a project with Wasi.Sdk:

dotnet new console -o MyFirstWasiApp
cd MyFirstWasiApp
dotnet add package Wasi.Sdk -v 0.1.3-preview.10012

• Modify Program.cs as follows:

GC.Collect();
Console.WriteLine("GC successful.");

• Build the project with dotnet build
• Install/download wasmtime 6.0.0 and run: wasmtime bin/Debug/net7.0/MyFirstWasiApp.wasm

Expected behavior: Prints GC successful. and returns a 0 exit code.

Actual Behavior: Prints the following assertion error, and returns an 1 exit code:

[wasm_trace_logger] * Assertion at /home/runner/work/dotnet-wasi-sdk/dotnet-wasi-sdk/modules/runtime/src/mono/mono/metadata/sgen-stw.c:77, condition `info->client_info.stack_start >= info->client_info.info.stack_start_limit && info->client_info.stack_start < info->client_info.info.stack_end' not met

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 uses Wasmtime to run these plugins in a sandboxed environment, using a defined API (functions that the WASM can import and may export).

Thank you!

[HermanSchoenfeld]

Issue is still occuring. How is WASI going to be useful if this happens?

[kpreisser]

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).