[browser] spinning in ".NET runtime already exited with"

[pavelsavara]

assert_runtime_running()

See details in #123523

[dotnet-policy-service]

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

[ArcadeMode]

@pavelsavara could you give me some pointers on running the tests with the CoreCLR wasm runtime? I havent found any docs in the repo and attempts at extracting from the Azure Pipeline logs havent been productive either.

So far Ive been using these commands to run tests on mono

build everything:

.\dotnet.cmd build /p:TargetOS=browser /p:TargetArchitecture=wasm /p:Configuration=Release

run test class

.\dotnet.cmd build /t:Test /p:TargetOS=browser /p:TargetArchitecture=wasm /p:Configuration=Release /p:Scenario=WasmTestOnChrome /p:WasmTestAppArgs="-class System.Runtime.InteropServices.JavaScript.Tests.JSExportTest" src\libraries\System.Runtime.InteropServices.JavaScript\tests\System.Runtime.InteropServices.JavaScript.UnitTests\System.Runtime.InteropServices.JavaScript.Tests.csproj

as far as I can get from the logs now I should add /p:RuntimeFlavor=CoreCLR. Which gives me build errors like WasmTriggerPublishApp for CoreCLR not implemented followed by an expectable entrypoint not found when running tests or \runtime\src\mono\browser\browser.proj(62,5): error MSB4044: The "ManagedToNativeGenerator" task was not given a value for the required parameter "ReversePInvokeOutputPath".

Some help would be appreciated.

[pavelsavara]

you will need to rm -rf artifacts or start building coreCLR flavor in another checkout folder of runtime repo. They can't coexist in artifacts with Mono.
/p:RuntimeFlavor=CoreCLR does the trick. Or env variable $env:RuntimeFlavor="CoreCLR"

[ArcadeMode]

is this completed with #123523?

[pavelsavara]

I think it's not. You solved (one) trigger, I want to make sure the spinning can't happen even when there is problem with the runtime code. The abort should work better even for unexpected failures

[ArcadeMode]

I have taken another look at this, currently the code on main does not seem to suffer from this issue anymore. What I have done:

• Make a local mono wasm build
• Create a project, ensure it uses the local build
• Remove the guards added in [browser] throw and marshal exception caused by invalid arguments in Tasks #123523
• Add method that takes Task<short> parameter, pass it Promise.resolve(1<<16) so the value fails the value assertions
• Observe the former issue with ".NET runtime already exited with" but only once

Formerly the last step woudl include the same message nested hundreds of times. Some recent change has resolved this spinning behavior. Given this observation, what are the next steps wrt this issue?

[pavelsavara]

It's quite possible that I fixed it with one of
https://github.com/dotnet/runtime/pull/123726/changes#diff-81bb02595eceb101a1d01750896a8cef522decbc603d08993fc77239f13786f1
https://github.com/dotnet/runtime/pull/124969/changes#diff-81bb02595eceb101a1d01750896a8cef522decbc603d08993fc77239f13786f1

I will close it and we can open another if it happens again