[browser][mt] Running any Thread for longer than 5000 ms crashes runtime (Blazor)

[IsaMorphic]

Description

Spawning any long-running Task or Thread from the main thread for longer than 5000 ms kills application and runtime when using Blazor.

Reproduction Steps

1. Create empty Blazor app and use current main build of runtime in project file
2. Use Task.Run, Thread.Start or async/await anywhere in the app with a long-running task (importantly, NOT Task.Yield or Task.Delay)
3. Observe the error and runtime crash.

Expected behavior

I should be able to start a task from anywhere on the main thread using Task.Run in a Blazor app and not have the runtime crash after 5000ms

Actual behavior

Runtime crashes with error (screenshot above)

Regression?

This previously worked perfectly on the official release build of .NET 8 Preview 4.

Known Workarounds

None

Configuration

No response

Other information

No response

[IsaMorphic]

Most likely this change is the cause of the issue: #86278

Edit:
After reverting the PR locally and trying the reproduction steps again, I have found that the error persists.

[ghost]

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

Issue Details

---

Description

Spawning any long-running Task or Thread from the main thread for longer than 5000 ms kills application and runtime when using Blazor.

Reproduction Steps

1. Create empty Blazor app and use current main build of runtime in project file
2. Use Task.Run, Thread.Start or async/await anywhere in the app with a long-running task (importantly, NOT Task.Yield or Task.Delay)
3. Observe the error and runtime crash.

Expected behavior

I should be able to start a task from anywhere on the main thread using Task.Run in a Blazor app and not have the runtime crash after 5000ms

Actual behavior

Runtime crashes with error (screenshot above)

Regression?

This previously worked perfectly on the official release build of .NET 8 Preview 4.

Known Workarounds

None

Configuration

No response

Other information

No response

Author:	IsaMorphic
Assignees:	-
Labels:	arch-wasm, untriaged, area-VM-threading-mono
Milestone:	-

[lambdageek]

@IsaMorphic Can you say a bit more about what's in the body of the long-running task? Is it compute-intensive? doing a synchronous call to JS that takes longer than 5 seconds? calling some native wasm code (like C code)?

In principle if the long-running task is just a compute loop in C# it should be trying to safepoint at backward branches in the loops... unless we're failing to emit the safepointing opcodes for some reason...

[IsaMorphic]

@lambdageek Of course. It is definitely a compute intensive task in .NET land. No interop is happening inside of it.

[pavelsavara]

This is GC trying to suspend a thread. Probably UI thread is unbalanced on GC state.

[pavelsavara]

Related #96190

[pavelsavara]

@lambdageek is there way how to test safepoint with unit test ?

[lambdageek]

@lambdageek is there way how to test safepoint with unit test ?

Start a GC

[pavelsavara]

Create tight for loop and make sure it runs longer than MONO_SLEEP_ABORT_LIMIT.
And start GC on the other thread, right ?
Could we do better ?

[lambdageek]

Well it's cooperative suspension, so we can add an icall that intentionally forgets to do a GC state transition and calls sleep. then call that on thread 1 and have thread 2 trigger a GC. I think that would behave a little better in the chrome debugger than doing a tight loop.

[IsaMorphic]

Any updates on this investigation / fix? I'm eagerly awaiting the moment that this bug is squashed, as I am building an app that heavily relies on this functionality!

[pavelsavara]

@IsaMorphic is it still possible to replicate with the latest build ?

You can try it with nightly build https://aka.ms/dotnet/9.0.1xx/daily/dotnet-sdk-win-x64.zip

[dotnet-policy-service]

This issue has been marked needs-author-action and may be missing some important information.

[dotnet-policy-service]

This issue has been automatically marked no-recent-activity because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will remove no-recent-activity.

[dotnet-policy-service]

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.