[WebAssembly] AOT + WasmEnableExceptionHandling (false) - Does not start on iOS

[iXyles]

Description

After swapping the new default of "WasmEnableExceptionHandling" in net8.0 to false again, to support older versions of Chrome. We are no longer able to start the webassembly app on an iOS device (v17.0.3 & latest). Why we need it to be off in our case: A customer of ours runs Windows 7, where Chrome 109 is the latest, which forces to set this to false - otherwise we got a different error that the browser did not support the new wasm exception handling.

From my testing this has to do with a combination of AOT and WasmExceptionHandling. The loading gets stuck on 100% when it starts to boot the WASM part.

Reproduction Steps

Base example: https://github.com/iXyles/net8-ios-aot-old-exception-handling/tree/6fac82b2e461e33b6f398e04f0e8a748dd7c6e46 & follow steps in ReadMe.

Otherwise:

1. Create a new blazor webassembly standalone project
2. Edit csproj to have: <RunAOTCompilation>true</RunAOTCompilation> <WasmEnableExceptionHandling>false</WasmEnableExceptionHandling> <WasmEnableSIMD>false</WasmEnableSIMD>
3. Publish the project with Release.
4. Host the published files
5. Try open the webassembly app on an iOS device.

I have not tested on an iOS simulator, only a real device. Loads fine on MacOS (latest)

Expected behavior

When setting WasmExceptionHandling to false with AOT it should still run on iOS safari as previous .net7.

Actual behavior

WASM app does not start as expected on iOS devices.

Regression?

Worked fine previously in net7.x when the exception handling was set to false by default.

Known Workarounds

Setting the Exception Handling to true (however as described above, it is not a case we can really do due to customer needs)

Configuration

iOS 17.0.3 iOS 17.2

Other information

[Warning] MONO_WASM: Exception marshalling result of JS promise to CS:  – 39887112 (dotnet.runtime.8.0.0.2xhvpccfjq.js, line 3)
[Error] 39855392
    ___cxa_throw (dotnet.native.8.0.0.gg8ywv7cny.js:8:17161)
    <?>.wasm-function[26725]
    <?>.wasm-function[26488]
    <?>.wasm-function[28891]
    <?>.wasm-function[28266]
    <?>.wasm-function[28272]
    <?>.wasm-function[28296]
    <?>.wasm-function[33942]
    kr (dotnet.runtime.8.0.0.2xhvpccfjq.js:3:35395)
    (anonymous function) (dotnet.runtime.8.0.0.2xhvpccfjq.js:3:208699)
    Mr (dotnet.runtime.8.0.0.2xhvpccfjq.js:3:37421)
    Pr (dotnet.runtime.8.0.0.2xhvpccfjq.js:3:37561)

Error from console when checking the web inspector with Safari on the device.

[ghost]

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

Issue Details

---

### Description After swapping the new default of "WasmExceptionHandling" in net8.0 to false again, to support older versions of Chrome. We are no longer able to start the webassembly app on an iOS device (v17.0.3 & latest). Why we need it to be off in our case: A customer of ours runs Windows 7, where Chrome 109 is the latest, which forces to set this to false - otherwise we got a different error that the browser did not support the new wasm exception handling. From my testing this has to do with a combination of AOT and WasmExceptionHandling. The loading gets stuck on 100% when it starts to boot the WASM part. ### Reproduction Steps Base example: https://github.com/iXyles/net8-ios-aot-old-exception-handling/tree/6fac82b2e461e33b6f398e04f0e8a748dd7c6e46 & follow steps in ReadMe. Otherwise: 1. Create a new blazor webassembly standalone project 2. Edit csproj to have: `true` `false` `false` 3. Publish the project with Release. 4. Host the published files 5. Try open the webassembly app on an iOS device. I have not tested on an iOS simulator, only a real device. Loads fine on MacOS (latest) ### Expected behavior When setting WasmExceptionHandling to `false` with `AOT` it should still run on iOS safari as previous `.net7`. ### Actual behavior WASM app does not start as expected on iOS devices. ### Regression? Worked fine previously in net7.x when the exception handling was set to false by default. ### Known Workarounds Setting the Exception Handling to true (however as described above, it is not a case we can really do due to customer needs) ### Configuration iOS 17.0.3 iOS 17.2 ### Other information [Warning] MONO_WASM: Exception marshalling result of JS promise to CS: – 39887112 (dotnet.runtime.8.0.0.2xhvpccfjq.js, line 3) [Error] 39855392 ___cxa_throw (dotnet.native.8.0.0.gg8ywv7cny.js:8:17161) .wasm-function[26725] .wasm-function[26488] .wasm-function[28891] .wasm-function[28266] .wasm-function[28272] .wasm-function[28296] .wasm-function[33942] kr (dotnet.runtime.8.0.0.2xhvpccfjq.js:3:35395) (anonymous function) (dotnet.runtime.8.0.0.2xhvpccfjq.js:3:208699) Mr (dotnet.runtime.8.0.0.2xhvpccfjq.js:3:37421) Pr (dotnet.runtime.8.0.0.2xhvpccfjq.js:3:37561) Error from console when checking the web inspector with Safari on the device.

Author:	iXyles
Assignees:	-
Labels:	`arch-wasm`, `untriaged`, `area-VM-meta-mono`
Milestone:	-

[radical]

Could you please build with <WasmNativeStrip>false</WasmNativeStrip>, and then share the stack trace?

[iXyles]

Sure thing,

[Warning] MONO_WASM: Exception marshalling result of JS promise to CS:  – 39823384 (dotnet.runtime.8.0.0.2xhvpccfjq.js, line 3)
[Error] 39818096
    ___cxa_throw (dotnet.native.8.0.0.gg8ywv7cny.js:1220)
    <?>.wasm-function[mono_llvm_cpp_throw_exception]
    <?>.wasm-function[interp_runtime_invoke]
    <?>.wasm-function[mono_jit_runtime_invoke]
    <?>.wasm-function[do_runtime_invoke]
    <?>.wasm-function[mono_runtime_try_invoke]
    <?>.wasm-function[mono_runtime_invoke]
    <?>.wasm-function[mono_wasm_invoke_method_bound]
    kr (dotnet.runtime.8.0.0.2xhvpccfjq.js:3:35395)
    (anonymous function) (dotnet.runtime.8.0.0.2xhvpccfjq.js:3:208699)
    Mr (dotnet.runtime.8.0.0.2xhvpccfjq.js:3:37421)
    Pr (dotnet.runtime.8.0.0.2xhvpccfjq.js:3:37561)

[radical]

@pavelsavara marshaling issue?

[pavelsavara]

~~I'm not 100% sure but I found use-after-free bug in this code yesterday. I will create fix for it and port to Net8. We will see if this would be also fixed.~~

That probably not it. There is something like mono_llvm_cpp_catch_exception missing on the stack. @kg hinted.

[vargaz]

I can reproduce on safari as well.

[vargaz]

The problem seems to be with the #if JITERPRETER_ENABLE_SPECIALIZED_JIT_CALL code in do_jit_call (), it doesn't seem to catch the exception in non-wasm eh mode. @kg

[vargaz]

To repro with safari:

• build using dotnet publish /p:Configuration=Release
• run python -m http.server in bin/Release/net8.0/publish/wwwroot/
• go to localhost:8000 in safari

[kg]

We should probably just disable jiterp if wasm EH is unavailable. It's too hard for me to test it and we don't (AFAIK) have CI coverage for old safari.

[kg]

I'm going to try and set up a way to reproduce this in win7, since the report suggests that will also suffice.

[kg]

Edited the issue description because it was using an incorrect property name in a couple spots (this is our fault, the incorrect name appears in our msbuild properties in one place...)

[pavelsavara]

I'm going to try and set up a way to reproduce this in win7, since the report suggests that will also suffice.

Maybe you can also disable it for chrome ? guessing --js-flags='--experimental-wasm-eh false'

Or just --experimental-wasm-eh false for V8.

Also it should be easy to download old v8 version.

[kg]

I'm going to try and set up a way to reproduce this in win7, since the report suggests that will also suffice.

Maybe you can also disable it for chrome ? guessing --js-flags='--experimental-wasm-eh false'

Or just --experimental-wasm-eh false for V8.

Also it should be easy to download old v8 version.

It looks like Chrome 109 (current version for Win7) has Wasm EH turned on and it can't be turned off. Old V8 version is an option, but I'm not sure this issue would reproduce in v8 shell.