[browser][CoreCLR][R2R] Array.BinarySearch comparer exception aborts library tests

[lewing]

Description

While enabling trimmed browser CoreCLR ReadyToRun library tests for #133193, System.Tests.ArrayTests.BinarySearch_TypesNotIComparable_ThrowsInvalidOperationException<object> aborts the process. This is an R2R execution failure, not a missing trimming descriptor: the same existing test passes all four data rows in a clean aggressively trimmed build with R2R disabled.

Reproduction Steps

Build the browser CoreCLR runtime, libraries, host, packs, and host crossgen2. This was reproduced on runtime commit 798449390515fa02f4b20160bedc5e34f8fbdfb9 with the publishing prerequisites from #133378 at 245cb70d593f2c8f3a4e23bcc422e7da5926e15b. Enable the existing iOS ILLink.Descriptors.iOS.xml for browser aggressive trimming in System.Runtime.Tests, and remove the stale .ilproj Link metadata from its TestILAssembly project reference so VFS staging succeeds.

XHARNESS_COMMAND=test-browser ./dotnet.sh build /t:Test \
  src/libraries/System.Runtime/tests/System.Runtime.Tests/System.Runtime.Tests.csproj \
  /p:TargetOS=browser /p:TargetArchitecture=wasm /p:RuntimeFlavor=CoreCLR /p:Configuration=Release \
  /p:PublishReadyToRun=true /p:EnableAggressiveTrimming=true \
  /p:Scenario=WasmTestOnChrome /p:InstallChromeForTests=true /p:XunitShowProgress=true \
  '/p:WasmTestAppArgs=-method System.Tests.ArrayTests.BinarySearch_TypesNotIComparable_ThrowsInvalidOperationException'

Use clean project-specific browser-wasm obj/bin outputs when switching PublishReadyToRun to false; otherwise stale staging can cause an unrelated System.Runtime assembly-load failure.

The existing theory exercises non-generic and generic Array.BinarySearch overloads. Its failing data row uses two distinct object instances; the comparer exception is expected to be wrapped in InvalidOperationException. The precise failing overload has not yet been isolated.

Expected behavior

All four existing data rows pass, as they do with aggressive trimming enabled and R2R disabled.

Actual behavior

R2R discovers the theory, executes its Int32 row, starts its Object row, and terminates:

[STRT] ...BinarySearch_TypesNotIComparable_ThrowsInvalidOperationException<Int32>(array: [0], value: "")
[STRT] ...BinarySearch_TypesNotIComparable_ThrowsInvalidOperationException<Object>(array: [Object { }], value: Object { })
WASM EXIT 1
XHarness exit code: 71 (GENERAL_FAILURE)

No managed assertion failure is reported. With R2R disabled, the clean trimmed run reports Tests run: 4 Passed: 4 Failed: 0 Skipped: 0.

Regression?

Unknown. The observed distinction is R2R on versus off with trimming retained, not an older-versus-newer runtime comparison.

Known Workarounds

Disable R2R for the application. A narrowly scoped browser-R2R ActiveIssue can quarantine this theory during library-test bring-up without disabling interpreter coverage.

Configuration

Browser-wasm CoreCLR Release, macOS arm64 build host, Chromium 153.0.8010.0, bootstrap SDK 11.0.100-rc.1.26420.103. The served CoreLib contains a nonzero R2R table.

Other information

Related to library-test bring-up #133193. #133547 fixes a potentially related catch-resumption GC-mode bug, but has not been tested against this reproduction and is not established as its fix.

Note

This issue was generated by GitHub Copilot from local build and test results.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/crossgen-contrib
See info in area-owners.md if you want to be subscribed.

[AndyAyersMS]

Investigating... does not seem to be fixed by #133547

[AndyAyersMS]

Looks like issues with stale resume IPs. Try resumption checks can see stale values if their catches do not complete (say the catch throws, like it does here). Fix up shortly.

[dotnet-policy-service]

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

[dotnet-policy-service]

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