[wasm][R2R] Generic multidimensional array access traps with null function

[lewing]

Description

The browser-wasm ReadyToRun crossgen2smoke_donotalwaysusecrossgen2 test traps while executing the shared-generic DoGenericArrayTest<System.__Canon> method used by TestGenericMDArrayBehavior.

Crossgen2 successfully emits and validates the test's wasm image, but execution fails with RuntimeError: null function or function signature mismatch. The stack includes the interpreter/R2R transition thunks and a delay-load method-call helper.

The same failure is present in CI builds that do not contain the unrelated change from #133281, and it also appears in a current main rolling build.

Reproduction Steps

The existing test is:

src/tests/readytorun/crossgen2/crossgen2smoke_donotalwaysusecrossgen2.csproj

Build browser-wasm Checked CoreCLR and the test layout, then run the generated test with Crossgen2 enabled. CI reproductions:

• Main build 1584274 at 9b3c09618a80f73d44c8b9747a33cc6523c3b3fc, Helix job 0fe59be2-9782-4762-9af1-8a5c2bc22afc
• PR build 1583904, Helix job c9e93497-5f29-4aed-a934-3ab74e1c1ef9
• PR build 1584047, Helix job 2bce5f60-0dde-4bb6-a4ce-1b68a7b499d8

The relevant existing code is:

private static bool DoGenericArrayTest<T>(T testValue) where T : IEquatable<T>
{
 T[,] array = new T[2, 2];
 array[0, 0] = testValue;
 if (!CheckArrayVal(ref array[0, 0], testValue))
 return false;

 return testValue.Equals(array[0, 0]);
}

TestGenericMDArrayBehavior invokes it with int, SomeClass, and SomeLargeStruct; the failing compiled frame is the shared System.__Canon instantiation.

Expected behavior

The ReadyToRun smoke test completes successfully and its result is reported accurately by the containing Helix work item.

Actual behavior

RuntimeError: null function or function signature mismatch
 at crossgen2smoke_donotalwaysusecrossgen2_Program__DoGenericArrayTest<System___Canon>
 at WasmInterpreterToR2RThunk(iiip)
 ...
 at WasmR2RToInterpreterThunk(iiip)
 at WasmDelayLoadHelper->EagerImports->SignaturePointer_ReadyToRunHelper_DelayLoad_MethodCall(...)
 at crossgen2smoke_donotalwaysusecrossgen2_Program__TestGenericMDArrayBehavior

The individual test reports Actual: 1. In main build 1584274, the enclosing readytorun Helix work item nevertheless exits 0 after later tests complete, so the failure is not listed by Monitor Helix Jobs even though it is present in the console log.

Regression?

Unknown. Closed issue #129821 and merged PR #129825 fixed an earlier wasm R2R generic-dictionary lookup trap with the same top-level error. The current stack involves DoGenericArrayTest<System.__Canon> and a delay-load method-call helper. This may be a recurrence or an uncovered variant, but the exact relationship has not been established.

Known Workarounds

No product workaround has been verified. The affected smoke test can be narrowly disabled for browser-wasm while the issue is active, but unaffected ReadyToRun coverage should remain enabled.

Configuration

• CoreCLR browser-wasm
• Checked runtime
• ReadyToRun image generated with Crossgen2
• Azure Linux AMD64 Helix host
• Node.js 23.11.1 with --experimental-wasm-exnref --stack-size=8192

Other information

This failure reproduced in #133276 and #133281 CI against the same main base, de29e26a4f69da5d446900a6ba9d68ba3ddc5ba9, so it is not caused by #133281. It also remains visible in the console of the later main build 1584274.

This is tracked as a blocker for restoring the browser-wasm R2R runtime-test lane in #133305.

Note

This issue was created with GitHub Copilot.

[dotnet-policy-service]

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

[dotnet-policy-service]

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