…ease/8.0-staging

[automated] Merge branch 'release/8.0' => 'release/8.0-staging'

Backport of dotnet#112282 to release/8.0

We observed several crash reports in dotnet Android coming from
google play store, like this one:

dotnet#109921 (comment)

and it happens at the following callstack:

mono_class_setup_vtable_full at /__w/1/s/src/mono/mono/metadata/class-setup-vtable.c:900
init_io_stream_slots at /__w/1/s/src/mono/mono/metadata/icall.c:3378
ves_icall_System_IO_Stream_HasOverriddenBeginEndRead at /__w/1/s/src/mono/mono/metadata/icall.c:3437
 (inlined by) ves_icall_System_IO_Stream_HasOverriddenBeginEndRead_raw at /__w/1/s/src/mono/mono/metadata/../metadata/icall-def.h:228

Looking a little deeper at that that code path expects call to
mono_class_try_get_stream_class to succeed since it calls
mono_class_setup_vtable on returned class pointer. There are other
places where code expectes mono_class_try_get_[shortname]_class to
always succeed or it will assert. Other locations handles the case
where it returns NULL meaning that the class has been linked out.

After looking into the macro implementation generating the
mono_class_try_get_[shortname]_class functions it appears that it has
a race where one thread could return NULL even if the class successfully
gets loaded by another racing thread. Initially that might have
been intentionally and callers would need to redo the call, but then
there is no way for callers to distinct between hitting the race and
class not available. Adding to the fact that code would also expect that
some critical classes never fail loading, like what
init_io_stream_slots does, this race ended up in race conditions.

In the past, this particular race in init_io_stream_slots was hidden
due to multiple calls to mono_class_try_get_stream_class minimzing the
risk of a race to cause a crash. That implementation was however
changed by dotnet@e74da7c
ending up in just one call to mono_class_try_get_stream_class in the
critical paths.

Since code relies on mono_class_try_get_[shortname]_class to succeed
for some critical classes, code asserts if it returns NULL or crashes.
The fix will use acquire/release semantics on the static variable
guarding the cached type and make sure memory order is preserved
on both read and write. Previous implementation adopted a similar approach
but it took a copy of the static tmp_class into a local variable meaning
that memory order would not be guaranteed, even if it applied memory
barriers and volatile keywords on the static variables.

Fix also adds an assert into init_io_stream_slots since it expects
failures in calls to mono_class_try_get_stream_class as fatal.

Co-authored-by: lateralusX <[email protected]>

…id. (dotnet#112374)

Backport of dotnet#112358 to release/8.0

On Android we have seen ANR issues, like the one described in
dotnet#111485. After investigating
several different dumps including all threads it turns out that we
could end up in a deadlock when init a monitor since that code path
didn't use a coop mutex and owner of lock could end up in GC code
while holding that lock, leading to deadlock if another thread was
about to lock the same monitor init lock. In several dumps we see
the following two threads:

Thread 1:

syscall+28
__futex_wait_ex(void volatile*, bool, int, bool, timespec const*)+14
NonPI::MutexLockWithTimeout(pthread_mutex_internal_t*, bool, timespec const*)+384
sgen_gc_lock+105
mono_gc_wait_for_bridge_processing_internal+70
sgen_gchandle_get_target+288
alloc_mon+358
ves_icall_System_Threading_Monitor_Monitor_wait+452
ves_icall_System_Threading_Monitor_Monitor_wait_raw+583

Thread 2:

syscall+28
__futex_wait_ex(void volatile*, bool, int, bool, timespec const*)+144
NonPI::MutexLockWithTimeout(pthread_mutex_internal_t*, bool, timespec const*)+652
alloc_mon+105
ves_icall_System_Threading_Monitor_Monitor_wait+452
ves_icall_System_Threading_Monitor_Monitor_wait_raw+583

So in this scenario Thread 1 holds monitor_mutex that is not a coop
mutex and end up trying to take GC lock, since it calls,
mono_gc_wait_for_bridge_processing_internal, but since a GC is already
started (waiting on STW to complete), Thread 1 will block holding
monitor_mutex.

Thread 2 will try to lock monitor_mutex as well, and since its not a
coop mutex it will block on OS __futex_wait_ex without changing
Mono thread state to blocking, preventing the STW from processing.

Fix is to switch to coop aware implementation of monitor_mutex.

Normally this should have been resolved on Android since we run
hybrid suspend meaning we should be able to run a signal handler on the
blocking thread that would suspend it meaning that STW would continue,
but for some reason the signal can't have been executed in this case putting the app under coop suspend limitations.

This fix will take care of the deadlock, but if there are issues running
Signals on Android, then threads not attached to runtime using
coop attach methods could end up in similar situations
blocking STW.

Co-authored-by: lateralusX <[email protected]>

…ease/8.0-staging

[automated] Merge branch 'release/8.0' => 'release/8.0-staging'

…ails on WinSrv 2025 (dotnet#112472)

…otnet#112379) (dotnet#112494)

* Move generation of SuggestedBindingRedirects.targets to inner build

These targets depend on the AssemblyVersion of the library which is
specific to the inner-build of the library.  Generate them in the inner-build.

* Update src/libraries/System.Resources.Extensions/src/System.Resources.Extensions.csproj

…ter (dotnet#111310) (dotnet#112008)

The wrapper was relatively recently changed to icall into mono_get_addr_compiled_method in order to obtain a native function pointer to call using calli. This is incorrect on interpreter where we expect an `InterpMethod*`. This commit adds a new opcode instead, that on jit it goes through the same icall path, while on interpeter in similarly computes the appropiate method to call.

On a separate track, it might be useful to investigate whether the necessary delegate invoke wrapper should have been present in the aot image and not be executed with the interpreter in the first place.

Co-authored-by: Steve Pfister <[email protected]>

…ificateDirectory (dotnet#112530)

…12790)

- On Windows, checking CPU utilization seems to involve a small amount of overhead, which can become noticeable or even significant in some scenarios. This change makes the intervals of time over which CPU utilization is computed configurable. Increasing the interval increases the period at which CPU utilization is updated. The same config var can also be used to disable CPU utilization checks and have features that use it behave as though CPU utilization is low.
- CPU utilization is used by the starvation heuristic and hill climbing. When CPU utilization is very high, the starvation heuristic reduces the rate of thread injection in starved cases. When CPU utilization is high, hill climbing avoids settling on higher thread count control values.
- CPU utilization is currently updated when the gate thread performs periodic activities, which happens typically every 500 ms when a worker thread is active. There is one gate thread per .NET process.
- In scenarios where there are many .NET processes running, and where many of them frequently but lightly use the thread pool, overall CPU usage may be relatively low, but the overhead from CPU utilization checks can bubble up to a noticeable portion of overall CPU usage. In a scenario involving 100s of .NET processes, it was seen that CPU utilization checks amount to 0.5-1% of overall CPU usage on the machine, which was considered significant.

…e generator (dotnet#113081) (dotnet#113151)

A balancing group can result in TransferCapture being emitted with a negative "capnum". If the compiler is running under a culture that uses something other than '-' as the negative sign, the resulting generated code will fail to compile.

…le (dotnet#112140)

* Include PDB for all TfmRuntimeSpecificPackageFile

Previously this would only include the PDB for the primary output which
missed any other additions to TfmRuntimeSpecificPackageFile - such as
those from references or packages.

* Update System.Diagnostics.EventLog.csproj

---------

Co-authored-by: Eric StJohn <[email protected]>

…ws (dotnet#112795)

* Stop counting work items from ThreadPoolTypedWorkItemQueue for ThreadPool.CompletedWorkItemCount (dotnet#106854)

* Stop counting work items from ThreadPoolTypedWorkItemQueue as completed work items

---------

Co-authored-by: Eduardo Manuel Velarde Polar <[email protected]>
Co-authored-by: Koundinya Veluri <[email protected]>

* Make counting of IO completion work items more precise on Windows

- Follow-up to dotnet#106854. Issue: dotnet#104284.
- Before the change, the modified test case often yields 5 or 6 completed work items, due to queue-processing work items that happen to not process any user work items. After the change, it always yields 4.
- Looks like it doesn't hurt to have more-precise counting, and there was a request to backport a fix to .NET 8, where it's more necessary to fix the issue

---------

Co-authored-by: Eduardo Velarde <[email protected]>
Co-authored-by: Eduardo Manuel Velarde Polar <[email protected]>

Backport of dotnet#113280

…otnet#111666)

* Change assembler to clang in android MonoAOT

* Disabled NdkToolFinder task

* Port changes to sample app

* Allowed overwriting AsOptions

* Since we bumped the NDK in dotnet/dotnet-buildtools-prereqs-docker#1278, libClang.so is no longer found in the place we expect. As a result, the android aot offsets won't be generated and the dedicated CI leg will fail.

This change fixes the path.

* Backported parts of dotnet#96332

* Fix build with Android 26 NDK (which has some nullability annotations) (dotnet#97976)

* Fix build with Android 26 NDK (which has some nullability annotations)

* One more error in System.Security.Cryptography.Native.Android

---------

Co-authored-by: Jeremi Kurdek <[email protected]>
Co-authored-by: Steve Pfister <[email protected]>
Co-authored-by: Filip Navara <[email protected]>
Co-authored-by: Jeremi Kurdek <[email protected]>
Co-authored-by: Jeff Schwartz <[email protected]>

…WBT runner (dotnet#113008)

Co-authored-by: vseanreesermsft <[email protected]>

…50203.2 (dotnet#112503)

Microsoft.DotNet.XHarness.CLI , Microsoft.DotNet.XHarness.TestRunners.Common , Microsoft.DotNet.XHarness.TestRunners.Xunit
 From Version 8.0.0-prerelease.25064.4 -> To Version 8.0.0-prerelease.25103.2

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

…ld 20250213.1 (dotnet#112551)

Microsoft.DotNet.CilStrip.Sources , System.ComponentModel.TypeConverter.TestData , System.Data.Common.TestData , System.Drawing.Common.TestData , System.Formats.Tar.TestData , System.IO.Compression.TestData , System.IO.Packaging.TestData , System.Net.TestData , System.Private.Runtime.UnicodeData , System.Runtime.Numerics.TestData , System.Runtime.TimeZoneData , System.Security.Cryptography.X509Certificates.TestData , System.Text.RegularExpressions.TestData , System.Windows.Extensions.TestData
 From Version 8.0.0-beta.25071.1 -> To Version 8.0.0-beta.25113.1

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

…112504)

* Update dependencies from https://github.com/dotnet/arcade build 20250211.4

Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.Build.Tasks.Archives , Microsoft.DotNet.Build.Tasks.Feed , Microsoft.DotNet.Build.Tasks.Installers , Microsoft.DotNet.Build.Tasks.Packaging , Microsoft.DotNet.Build.Tasks.TargetFramework , Microsoft.DotNet.Build.Tasks.Templating , Microsoft.DotNet.Build.Tasks.Workloads , Microsoft.DotNet.CodeAnalysis , Microsoft.DotNet.GenAPI , Microsoft.DotNet.GenFacades , Microsoft.DotNet.Helix.Sdk , Microsoft.DotNet.PackageTesting , Microsoft.DotNet.RemoteExecutor , Microsoft.DotNet.SharedFramework.Sdk , Microsoft.DotNet.VersionTools.Tasks , Microsoft.DotNet.XUnitConsoleRunner , Microsoft.DotNet.XUnitExtensions
 From Version 8.0.0-beta.25060.1 -> To Version 8.0.0-beta.25111.4

* Update dependencies from https://github.com/dotnet/arcade build 20250214.5

Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.Build.Tasks.Archives , Microsoft.DotNet.Build.Tasks.Feed , Microsoft.DotNet.Build.Tasks.Installers , Microsoft.DotNet.Build.Tasks.Packaging , Microsoft.DotNet.Build.Tasks.TargetFramework , Microsoft.DotNet.Build.Tasks.Templating , Microsoft.DotNet.Build.Tasks.Workloads , Microsoft.DotNet.CodeAnalysis , Microsoft.DotNet.GenAPI , Microsoft.DotNet.GenFacades , Microsoft.DotNet.Helix.Sdk , Microsoft.DotNet.PackageTesting , Microsoft.DotNet.RemoteExecutor , Microsoft.DotNet.SharedFramework.Sdk , Microsoft.DotNet.VersionTools.Tasks , Microsoft.DotNet.XUnitConsoleRunner , Microsoft.DotNet.XUnitExtensions
 From Version 8.0.0-beta.25060.1 -> To Version 8.0.0-beta.25114.5

* Bump SdkVersionForWorkloadTesting to 8.0.113

---------

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Alexander Köplinger <[email protected]>
Co-authored-by: Larry Ewing <[email protected]>
Co-authored-by: Carlos Sánchez López <[email protected]>

…dotnet#112520)

* Update dependencies from https://github.com/dotnet/hotreload-utils build 20250213.1

Microsoft.DotNet.HotReload.Utils.Generator.BuildTool
 From Version 8.0.0-alpha.0.25077.2 -> To Version 8.0.0-alpha.0.25113.1

* Update dependencies from https://github.com/dotnet/hotreload-utils build 20250217.1

Microsoft.DotNet.HotReload.Utils.Generator.BuildTool
 From Version 8.0.0-alpha.0.25077.2 -> To Version 8.0.0-alpha.0.25117.1

* Update dependencies from https://github.com/dotnet/hotreload-utils build 20250224.2

Microsoft.DotNet.HotReload.Utils.Generator.BuildTool
 From Version 8.0.0-alpha.0.25077.2 -> To Version 8.0.0-alpha.0.25124.2

---------

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Carlos Sánchez López <[email protected]>