[.NET 7.0 + WASM AOT] App crash after update

[DierkDroth]

Description

After updating to latest .NET 7 my Platform UNO app crashes 100% reproducible (screenshot below). Please see the original issue report here

The failing code looks like this:
(string, object) result = await TaskCompletionSource<(string, object)>.Task
(there is additional information including logs available on the link above)

Unfortunately I'm unable to create a repo -> there must be some side condition involved which makes it hard to reproduce.

Would you have any idea what might be going wrong and what could be done to further isolate the crash?

Thanks in advance

Reproduction Steps

Pls see above

Expected behavior

WASM AOT should not crash

Actual behavior

Crash on WASM AOT

Regression?

Yes, earlier on this year I had (a prior version of) my app running on .NET 6 + WASM AOT and did not experience that crash.

Known Workarounds

No response

Configuration

• WASM AOT in a Platform UNO app
• latest .NET 7
• on latest Windows 11, x64

Other information

No response

[SamMonoRT]

cc @lewing @vargaz

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

Issue Details

---

Description

After updating to latest .NET 7 my Platform UNO app crashes 100% reproducible (screenshot below). Please see the original issue report here

The failing code looks like this:
(string, object) result = await TaskCompletionSource<(string, object)>.Task
(there is additional information including logs available on the link above)

Unfortunately I'm unable to create a repo -> there must be some side condition involved which makes it hard to reproduce.

Would you have any idea what might be going wrong and what could be done to further isolate the crash?

Thanks in advance

Reproduction Steps

Pls see above

Expected behavior

WASM AOT should not crash

Actual behavior

Crash on WASM AOT

Regression?

Yes, earlier on this year I had (a prior version of) my app running on .NET 6 + WASM AOT and did not experience that crash.

Known Workarounds

No response

Configuration

• WASM AOT in a Platform UNO app
• latest .NET 7
• on latest Windows 11, x64

Other information

No response

Author:	DierkDroth
Assignees:	vargaz
Labels:	arch-wasm, area-Codegen-AOT-mono
Milestone:	7.0.x

[DierkDroth]

@SamMonoRT @vargaz I just tested the offending project with <WasmShellMonoRuntimeExecutionMode>Interpreter</WasmShellMonoRuntimeExecutionMode>
... and would not encounter that problem.

-> There clearly appears to be something wrong with
<WasmShellMonoRuntimeExecutionMode>InterpreterAndAOT</WasmShellMonoRuntimeExecutionMode>

Please let me know if you needed anything else - apart from a repo, which I unfortunately was unable to create - to resolve that regression.

[vargaz]

UNO has its own build system, its own specific way of using AOT, etc, so it might be better to report this to them, they might be able to create a testcase.

[DierkDroth]

@vargaz thanks for your feedback.

Interesting, @jeromelaban pointed me here as I posted this issue on the UNO space, since he felt this was a .NET WASM issue.
I feel like the man in the middle here...

[jeromelaban]

@DierkDroth As I mentioned previously, neither the .NET team or Uno Team can work on this issue if there is no repro sample. It's best if you try making a sample out of your code so we can analyze further.

@vargaz This looks like a case of generic generic incorrect interp transitionsm, when proper stack traces are reported:

Unhandled dispatcher exception: RuntimeError: null function or function signature mismatch (RuntimeError: null function or function signature mismatch
    at Unusual_Common_System_Runtime_CompilerServices_AsyncTaskMethodBuilder_1_object_AwaitUnsafeOnCompleted_System_Runtime_CompilerServices_TaskAwaiter_1_System_ValueTuple_2_string_object_Unusual_Db_DbConnection__ResponseAsyncd__50_System_Runtime_CompilerServices_TaskAwaiter_1_System_ValueTuple_2_string_object__Unusual_Db_DbConnection__ResponseAsyncd__50_ (https://stage.unusual-suite.com/app/wasm/Latest/package_685d0fc76a7f7353d2189e6e8e3f0e7056a95bd2/dotnet.wasm:wasm-function[33293]:0xfe71e5)
    at Unusual_Common_Unusual_Db_DbConnection__ResponseAsyncd__50_MoveNext (https://stage.unusual-suite.com/app/wasm/Latest/package_685d0fc76a7f7353d2189e6e8e3f0e7056a95bd2/dotnet.wasm:wasm-function[32659]:0xf6812f)
    at aot_instances_aot_wrapper_gsharedvt_in_sig_void_cl26_Mono_dValueTuple_602_3cint_2c_20int_3e_ (https://stage.unusual-suite.com/app/wasm/Latest/package_685d0fc76a7f7353d2189e6e8e3f0e7056a95bd2/dotnet.wasm:wasm-function[1354]:0xe0fd3)
    at jit_call_cb (https://stage.unusual-suite.com/app/wasm/Latest/package_685d0fc76a7f7353d2189e6e8e3f0e7056a95bd2/dotnet.wasm:wasm-function[20664]:0x81625d)
    at mono_llvm_cpp_catch_exception (https://stage.unusual-suite.com/app/wasm/Latest/package_685d0fc76a7f7353d2189e6e8e3f0e7056a95bd2/dotnet.wasm:wasm-function[20274]:0x7ff838)
    at do_jit_call (https://stage.unusual-suite.com/app/wasm/Latest/package_685d0fc76a7f7353d2189e6e8e3f0e7056a95bd2/dotnet.wasm:wasm-function[21694]:0x8694dc)
    at interp_exec_method (https://stage.unusual-suite.com/app/wasm/Latest/package_685d0fc76a7f7353d2189e6e8e3f0e7056a95bd2/dotnet.wasm:wasm-function[5926]:0x2607c7)
    at interp_runtime_invoke (https://stage.unusual-suite.com/app/wasm/Latest/package_685d0fc76a7f7353d2189e6e8e3f0e7056a95bd2/dotnet.wasm:wasm-function[58514]:0x1717e5d)
    at mono_jit_runtime_invoke (https://stage.unusual-suite.com/app/wasm/Latest/package_685d0fc76a7f7353d2189e6e8e3f0e7056a95bd2/dotnet.wasm:wasm-function[58137]:0x170f92d)
    at do_runtime_invoke (https://stage.unusual-suite.com/app/wasm/Latest/package_685d0fc76a7f7353d2189e6e8e3f0e7056a95bd2/dotnet.wasm:wasm-function[11643]:0x48df48))
    ```

[DierkDroth]

@jeromelaban I perfectly understand that a repo would help much to isolate the issue. As you know I'm always trying to create a repo as I reported an issue.

Unfortunately I failed in this case, since - this is my speculation - there is a side condition involved which I'm not aware (yet) and which makes the code fail.

[DierkDroth]

@jeromelaban @vargaz I tried to further isolate the case and replaced

(string, object) result = await TaskCompletionSource<(string, object)>.Task

... by

object[] result = await TaskCompletionSource<object[]>.Task

Success! The app no longer crashes!

Anyway, it's concerning that the combination generics + (value) tuple + XXX (unknown factor which prevents me creating a repo) would crash InterperterAndAOT where Interpreter would work as expected.
Also: this is clear regression, since I had the same combo of generics + (value) tuple in my app with .NET 6 and never experienced the failure before.