Fix double monitor release in synchronized runtime-async methods

[Copilot]

Awaiting a faulted awaitable returned by a synchronized method can release the monitor twice, replacing the original exception or releasing a caller-owned recursive acquisition.

• JIT: Clear lvaMonAcquired immediately after the importer-generated monitor exit, preventing a subsequent await exception from triggering another release. The released-state value is 0; 1 means acquired.
• Regression coverage: Extend the existing Task and ValueTask tests to verify exception identity and monitor ownership, with and without a caller-held lock.

• Fixes JIT: (bug) Runtime-async version of a Synchronized method releases the monitor twice, replacing the real exception and corrupting the caller's lock #133865

[azure-pipelines]

Azure Pipelines:
16 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @akoeplinger, @matouskozak, @simonrozsival
See info in area-owners.md if you want to be subscribed.

[azure-pipelines]

Azure Pipelines:
Successfully started running 5 pipeline(s).
11 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

🔵 Needs a closer look

The JIT monitor-release change affects exception handling and lock ownership, warranting final human review.

Pull request overview

Fixes double monitor release in synchronized runtime-async methods and adds regression coverage.

Changes:

• Clears lvaMonAcquired after monitor release.
• Tests Task and ValueTask exception identity and lock ownership.

File summaries

File	Description
src/tests/async/regression/synchronized-async-version.cs	Adds synchronized async exception and ownership tests.
src/coreclr/jit/importer.cpp	Prevents duplicate monitor release during fault handling.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 0
• Review effort level: Lite

[jakobbotsch]

cc @dotnet/jit-contrib PTAL @EgorBo

I will backport this. To my surprise we actually have synchronized task-returning methods in the BCL that may throw (due to cancellation):

runtime/src/libraries/System.Private.CoreLib/src/System/IO/TextWriter.cs

Lines 1088 to 1098 in f9b470a

	[MethodImpl(MethodImplOptions.Synchronized)]
	public override Task WriteAsync(StringBuilder? value, CancellationToken cancellationToken = default)
	{
	if (cancellationToken.IsCancellationRequested)
	{
	return Task.FromCanceled(cancellationToken);
	}
	Write(value);
	return Task.CompletedTask;
	}

So this problem is reproducible with:

using StreamWriter sw = new StreamWriter(new MemoryStream());
var sb = new StringBuilder();
await TextWriter.Synchronized(sw).WriteLineAsync(sb, new CancellationToken(canceled: true));

in .NET 11 with runtime async enabled.

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[jakobbotsch]

/ba-g Failure is the one fixed by #133775

[jakobbotsch]

/backport to release/11.0

[github-actions]

Started backporting to release/11.0 (link to workflow run)