_marshal_task_to_cs calls complete_task on already completed task

[dlemstra]

Description

We have a project that uses <RuntimeIdentifier>browser-wasm</RuntimeIdentifier> and copies the content of AppBundle to a JavaScript project. This dotnet project contains a lot of libraries and we have an issue were we could not found the root cause for. We are unable to reproduce it in a small project . I am adding the error message here because this might be related:

dotnet.js:14  System.TypeLoadException: Could not find method '.ctor' due to a type load error: Parent class
 failed to load, due to: Failed to load generic parameter 1 assembly:CompanyName.dll type:CompanyClass`2 
member:(null) assembly:CompanyName.dll type:OtherCompanyClass`2 member:(null)

To try to work around this problem we tried an AOT build (RunAOTCompilationAfterBuild). But we then got the following error reported in the console:

An attempt was made to transition a task to a final state when it had already completed.

This seems to be happening because of this call:

runtime/src/mono/wasm/runtime/marshal-to-cs.ts

Line 323 in 5331448

runtimeHelpers.javaScriptExports.complete_task(gc_handle, reason, null, undefined);

That is happening after this call:

runtime/src/mono/wasm/runtime/marshal-to-cs.ts

Line 318 in 5331448

runtimeHelpers.javaScriptExports.complete_task(gc_handle, null, data, res_converter || _marshal_cs_object_to_cs);

that fails with the following error message:

RuntimeError: null function or function signature mismatch
    at dotnet.wasm:wasm-function[268195]:0x792fb17
    at dotnet.wasm:wasm-function[278722]:0x7d6dd5c
    at invoke_viiiii (dotnet/dotnet.js:14:237182)
    at dotnet.wasm:wasm-function[278817]:0x7d7bda0
    at dotnet.wasm:wasm-function[293]:0x1850ff
    at dotnet.wasm:wasm-function[306692]:0x9bbb73a
    at invoke_vi (dotnet/dotnet.js:14:235216)
    at dotnet.wasm:wasm-function[306970]:0x9bd7ebc
    at dotnet.wasm:wasm-function[306662]:0x9bbad05
    at dotnet.wasm:wasm-function[306599]:0x9bac4f5

Reproduction Steps

We are unable to create a small sample project that can be used to reproduce this issue.

Expected behavior

That the RuntimeError: null function or function signature mismatch error is reported.

Actual behavior

We are getting this error message instead An attempt was made to transition a task to a final state when it had already completed..

Regression?

No response

Known Workarounds

No response

Configuration

.NET 7.0.304
Windows

<OutputType>Exe</OutputType>
<RuntimeIdentifier>browser-wasm</RuntimeIdentifier>

Other information

No response

[ghost]

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

Issue Details

---

Description

We have a project that uses <RuntimeIdentifier>browser-wasm</RuntimeIdentifier> and copies the content of AppBundle to a JavaScript project. This dotnet project contains a lot of libraries and we have an issue were we could not found the root cause for. We are unable to reproduce it in a small project . I am adding the error message here because this might be related:

dotnet.js:14  System.TypeLoadException: Could not find method '.ctor' due to a type load error: Parent class
 failed to load, due to: Failed to load generic parameter 1 assembly:CompanyName.dll type:CompanyClass`2 
member:(null) assembly:CompanyName.dll type:OtherCompanyClass`2 member:(null)

To try to work around this problem we tried an AOT build (RunAOTCompilationAfterBuild). But we then got the following error reported in the console:

An attempt was made to transition a task to a final state when it had already completed.

This seems to be happening because of this call:

runtime/src/mono/wasm/runtime/marshal-to-cs.ts

Line 323 in 5331448

runtimeHelpers.javaScriptExports.complete_task(gc_handle, reason, null, undefined);

That is happening after this call:

runtime/src/mono/wasm/runtime/marshal-to-cs.ts

Line 318 in 5331448

runtimeHelpers.javaScriptExports.complete_task(gc_handle, null, data, res_converter || _marshal_cs_object_to_cs);

that fails with the following error message:

RuntimeError: null function or function signature mismatch
    at dotnet.wasm:wasm-function[268195]:0x792fb17
    at dotnet.wasm:wasm-function[278722]:0x7d6dd5c
    at invoke_viiiii (dotnet/dotnet.js:14:237182)
    at dotnet.wasm:wasm-function[278817]:0x7d7bda0
    at dotnet.wasm:wasm-function[293]:0x1850ff
    at dotnet.wasm:wasm-function[306692]:0x9bbb73a
    at invoke_vi (dotnet/dotnet.js:14:235216)
    at dotnet.wasm:wasm-function[306970]:0x9bd7ebc
    at dotnet.wasm:wasm-function[306662]:0x9bbad05
    at dotnet.wasm:wasm-function[306599]:0x9bac4f5

Reproduction Steps

We are unable to create a small sample project that can be used to reproduce this issue.

Expected behavior

That the RuntimeError: null function or function signature mismatch error is reported.

Actual behavior

We are getting this error message instead An attempt was made to transition a task to a final state when it had already completed..

Regression?

No response

Known Workarounds

No response

Configuration

.NET 7.0.304
Windows

<OutputType>Exe</OutputType>
<RuntimeIdentifier>browser-wasm</RuntimeIdentifier>

Other information

No response

Author:	dlemstra
Assignees:	-
Labels:	arch-wasm, untriaged, area-System.Runtime.InteropServices.JavaScript
Milestone:	-

[radical]

cc @kg @pavelsavara

[pavelsavara]

Failed to load generic parameter 1 could be trimming problem, reflection problem or some non-wasm native dependency in the DLL preventing the class from loading. To troubleshoot it, I think you could try to create simpler app, where you try to instantiate that type yourself.

already completed task is more interesting from our perspective, if you could give us small sample app to reproduce it. Possibly you are doing something nasty with JS promises ?

[dlemstra]

Thanks for your quick response. I will try to create a smaller app where this can be reproduced but that won't be an easy task due to the complexity of the library and all it's dependencies. And it also looks like that small sample could be used to diagnose both issues. Adding both <WasmEmitSymbolMap>true</WasmEmitSymbolMap> and <WasmNativeStrip>false</WasmNativeStrip> is telling me that the issue is occuring at the same spot. And I also just did a quick search for _marshal_task_to_cs inside the issues (should have done that earlier) and I found #77122 that mentions something similar. Maybe our code also causes the dotnet.wasm to break and then this issue will occur?

EDIT: The workaround did not work. I was watching something older due to some strange (non browser?) caching issues with the .dll files.

[kg]

already completed task is more interesting from our perspective, if you could give us small sample app to reproduce it. Possibly you are doing something nasty with JS promises ?

Perhaps the process of completing the task (running completion handlers?) is failing, so when we attempt to handle the exception, we go in and try to complete it with the new exception and that fails?

[kg]

already completed task is more interesting from our perspective, if you could give us small sample app to reproduce it. Possibly you are doing something nasty with JS promises ?

Perhaps the process of completing the task (running completion handlers?) is failing, so when we attempt to handle the exception, we go in and try to complete it with the new exception and that fails?

Yes, looking at

runtime/src/mono/wasm/runtime/marshal-to-cs.ts

Lines 315 to 324 in cfe30c0

	value.then(data => {
	if (MonoWasmThreads)
	settleUnsettledPromise();
	runtimeHelpers.javaScriptExports.complete_task(gc_handle, null, data, res_converter || _marshal_cs_object_to_cs);
	teardown_managed_proxy(holder, gc_handle); // this holds holder alive for finalizer, until the promise is freed, (holding promise instead would not work)
	}).catch(reason => {
	if (MonoWasmThreads)
	settleUnsettledPromise();
	runtimeHelpers.javaScriptExports.complete_task(gc_handle, reason, null, undefined);
	teardown_managed_proxy(holder, gc_handle); // this holds holder alive for finalizer, until the promise is freed

I think that's what happened here. The way it's written, if we fail during complete_task or the call after it, we will attempt to complete the task again. We should either swallow the exception caused by a second task completion, or put in some logic to detect that it's already completed.