[browser] RuntimeError: memory access out of bounds at dotnet.native.wasm.mono_jiterp_tlqueue_purge_all

[dlemstra]

Description

We are running an angular application that creates and starts the runtime with Blazor.start and getDotnetRuntime(0). At some point our application gets this runtime error:

RuntimeError: memory access out of bounds
    at dotnet.native.wasm.mono_jiterp_tlqueue_purge_all (http://localhost:4200/assets/dotnet/dotnet.native.sg2y5d2zcg.wasm:wasm-function[446]:0x43172)
    at dotnet.native.wasm.mono_jiterp_free_method_data (http://localhost:4200/assets/dotnet/dotnet.native.sg2y5d2zcg.wasm:wasm-function[445]:0x430b0)
    at dotnet.native.wasm.interp_free_method (http://localhost:4200/assets/dotnet/dotnet.native.sg2y5d2zcg.wasm:wasm-function[156]:0x1af71)
    at dotnet.native.wasm.mono_jit_free_method (http://localhost:4200/assets/dotnet/dotnet.native.sg2y5d2zcg.wasm:wasm-function[4792]:0x139620)
    at dotnet.native.wasm.mono_runtime_free_method (http://localhost:4200/assets/dotnet/dotnet.native.sg2y5d2zcg.wasm:wasm-function[3661]:0xfb211)
    at dotnet.native.wasm.free_dynamic_method (http://localhost:4200/assets/dotnet/dotnet.native.sg2y5d2zcg.wasm:wasm-function[4255]:0x1187c7)
    at dotnet.native.wasm.reference_queue_process (http://localhost:4200/assets/dotnet/dotnet.native.sg2y5d2zcg.wasm:wasm-function[4418]:0x1252f7)
    at dotnet.native.wasm.mono_runtime_do_background_work (http://localhost:4200/assets/dotnet/dotnet.native.sg2y5d2zcg.wasm:wasm-function[4403]:0x124ebe)
    at dotnet.native.wasm.mono_background_exec (http://localhost:4200/assets/dotnet/dotnet.native.sg2y5d2zcg.wasm:wasm-function[1188]:0x5319a)
    at Yo (http://localhost:4200/assets/dotnet/dotnet.runtime.26xtx0erx2.js:3:55978)

This issue seems to be in the jiterpreter and we wanted to see what would happen when we disable this with the following settings:

<BlazorWebAssemblyJiterpreter>false</BlazorWebAssemblyJiterpreter>
<WasmBuildNative>true</WasmBuildNative>
<WasmNativeDebugSymbols>true</WasmNativeDebugSymbols>
<DebuggerSupport>true</DebuggerSupport>
<CompressionEnabled>false</CompressionEnabled>
<WasmNativeStrip>false</WasmNativeStrip>
<BlazorCacheBootResources>false</BlazorCacheBootResources>

This will add the following options to the blazor.boot.json file:

[
  "--no-jiterpreter-traces-enabled",
  "--no-jiterpreter-interp-entry-enabled",
  "--no-jiterpreter-jit-call-enabled"
]

But this does not seem to disable calling that method and results in the same runtime error.

Reproduction Steps

I am unable to provide a small sample that can be used to reproduce this issue.

Expected behavior

Setting <BlazorWebAssemblyJiterpreter>false</BlazorWebAssemblyJiterpreter> should disable the call to mono_jiterp_tlqueue_purge_all.

Actual behavior

The method is called.

Regression?

No response

Known Workarounds

No response

Configuration

.NET 9.0.100-rc.1.24452.12
Microsoft.AspNetCore.Components.WebAssembly 9.0.0-rc.1.24452.1

Other information

@pavelsavara was in a teams call where this runtime error was happening.

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to this area: @BrzVlad, @kotlarmilos
See info in area-owners.md if you want to be subscribed.

[pavelsavara]

cc @kg

I wonder why the jiterp was not disabled by the flags.

[pavelsavara]

there are 2 problems
a) access out of bounds
b) why jiterp was not disabled

Let's start by reproducing b)

[dlemstra]

It looks like the error is happening because shared_queues is still NULL.

With some debugging in the browser I noticed the following

global.get $GOT.data.internal.__memory_base
i32.const 6102076 // address of shared_queues?
i32.add 
i32.load // stack contains a single value that is zero
local.tee $var1 // $var1 is zero
i32.load offset=4 // stack contains the value 34821223

The value 34821223 is 4 bytes after memory address zero. I have also put a break point at (func $get_queue (;478;) (param $var0 i32) (result i32) and that method is never called to make sure that call $monoeg_g_ptr_array_new sets shared_queues.

I hope this helps the team figure out why this access out of bounds runtime error is happening.

[kg]

This bit of functionality is probably not guarded by the jiterpreter pref. It's a bit surprising that it's able to run during your application startup - this would require you to be creating enough dynamic methods to run out of memory and cause them to get GC'd. It shouldn't be too hard to prepare a fix, so I'll look into it.

[pavelsavara]

Maybe the application is heavily using OnPropertyChange events/delegates ?

[dlemstra]

The application where we are experiencing this runtime error is using a lot of OnPropertyChange events.

[pavelsavara]

We also learned that the mono_jiterp_tlqueue_purge_all exception appears also when the jiterp is enabled. It seems that mono_jiterp_tlqueue_purge_all would be executed before any jiterp tier-up ?

[GokulprasathVenkatachalam]

Hi Team,

We have updated to the latest .NET 9 RC2 and Visual Studio Preview, but we are still encountering a similar issue in our Blazor WASM project with SkiaSharp. The error details are as follows:

MONO_WASM: memory access out of bounds
RuntimeError: memory access out of bounds
    at dotnet.native.wasm.mono_jiterp_tlqueue_purge_all (http://localhost:5271/_framework/dotnet.native.b58uvdo7wg.wasm:wasm-function[444]:0x439a1)
    at dotnet.native.wasm.mono_jiterp_free_method_data (http://localhost:5271/_framework/dotnet.native.b58uvdo7wg.wasm:wasm-function[443]:0x438e2)
    at dotnet.native.wasm.interp_free_method (http://localhost:5271/_framework/dotnet.native.b58uvdo7wg.wasm:wasm-function[156]:0x1b74e)
    at dotnet.native.wasm.mono_jit_free_method (http://localhost:5271/_framework/dotnet.native.b58uvdo7wg.wasm:wasm-function[4790]:0x139f29)
    at dotnet.native.wasm.mono_runtime_free_method (http://localhost:5271/_framework/dotnet.native.b58uvdo7wg.wasm:wasm-function[3659]:0xfbb1a)
    at dotnet.native.wasm.free_dynamic_method (http://localhost:5271/_framework/dotnet.native.b58uvdo7wg.wasm:wasm-function[4253]:0x1190d0)
    at dotnet.native.wasm.reference_queue_process (http://localhost:5271/_framework/dotnet.native.b58uvdo7wg.wasm:wasm-function[4416]:0x125c00)
    at dotnet.native.wasm.mono_runtime_do_background_work (http://localhost:5271/_framework/dotnet.native.b58uvdo7wg.wasm:wasm-function[4401]:0x1257c7)
    at dotnet.native.wasm.mono_background_exec (http://localhost:5271/_framework/dotnet.native.b58uvdo7wg.wasm:wasm-function[1186]:0x539d8)
    at Yo (http://localhost:5271/_framework/dotnet.runtime.ju77aherdp.js:3:56077)
Uncaught RuntimeError RuntimeError: memory access out of bounds
    at $mono_jiterp_tlqueue_purge_all (localhost꞉5271/_framework/dotnet.native.b58uvdo7wg.wasm:1:276898)
    at $mono_jiterp_free_method_data (localhost꞉5271/_framework/dotnet.native.b58uvdo7wg.wasm:1:276707)
    at $interp_free_method (localhost꞉5271/_framework/dotnet.native.b58uvdo7wg.wasm:1:112463)
    at $mono_jit_free_method (localhost꞉5271/_framework/dotnet.native.b58uvdo7wg.wasm:1:1285930)
    at $mono_runtime_free_method (localhost꞉5271/_framework/dotnet.native.b58uvdo7wg.wasm:1:1030939)
    at $free_dynamic_method (localhost꞉5271/_framework/dotnet.native.b58uvdo7wg.wasm:1:1151185)
    at $reference_queue_process (localhost꞉5271/_framework/dotnet.native.b58uvdo7wg.wasm:1:1203201)
    at $mono_runtime_do_background_work (localhost꞉5271/_framework/dotnet.native.b58uvdo7wg.wasm:1:1202120)
    at $mono_background_exec (localhost꞉5271/_framework/dotnet.native.b58uvdo7wg.wasm:1:342489)
    at Yo (d:\Net9\NET9\NET9\wwwroot\_framework\https:\raw.githubusercontent.com\dotnet\runtime\990ebf52fc408ca45929fd176d2740675a67fab8\src\mono\browser\runtime\scheduling.ts:56:20)
    at callUserCallback (localhost꞉5271/_framework/dotnet.native.jafepmvuxs.js:7010:9)
    at <anonymous> (localhost꞉5271/_framework/dotnet.native.jafepmvuxs.js:7030:9)

We are also experiencing a similar issue after updating to SkiaSharp Preview 5.3:

MONO_WASM: memory access out of bounds
RuntimeError: memory access out of bounds
    at wasm://wasm/022efb7e:wasm-function[15510]:0x4f85b4
    at wasm://wasm/022efb7e:wasm-function[15509]:0x4f850b
    at wasm://wasm/022efb7e:wasm-function[15222]:0x4d3f6f
    at wasm://wasm/022efb7e:wasm-function[19856]:0x5cff82
    at wasm://wasm/022efb7e:wasm-function[18725]:0x599f16
    at wasm://wasm/022efb7e:wasm-function[19319]:0x5b3aa6
    at wasm://wasm/022efb7e:wasm-function[19482]:0x5bed4d
    at wasm://wasm/022efb7e:wasm-function[19467]:0x5be9d0
    at wasm://wasm/022efb7e:wasm-function[16252]:0x5064e7
    at Yo (http://localhost:5009/_framework/dotnet.runtime.ju77aherdp.js:3:56077)

Could you please confirm if these memory access out of bounds issues are resolved in the .NET 9 release or if there are any other packages that address this problem?

Regards,
Gokulprasath

[pavelsavara]

This is hopefully fixed in GA #108650
We didn't have a way to reproduce

[dlemstra]

I can confirm that this is fixed for us with net9.0.