Repository navigation
[wasm][CoreCLR][R2R] MethodBase.GetCurrentMethod returns itself instead of its caller #133617
Description
Description
System.Reflection.Tests.MethodBaseTests.Test_GetCurrentMethod fails in the trimmed browser CoreCLR R2R library tests. The same existing test passes in a clean, aggressively trimmed non-R2R build.
Reproduction Steps
Build browser CoreCLR libraries and packs, with host crossgen2, and run:
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:WasmTestAppArgs=-method System.Reflection.Tests.MethodBaseTests.Test_GetCurrentMethod'This uses the shared mobile trimming descriptors being enabled for browser in #133193, and the publishing prerequisite from #133378.
Expected behavior
MethodBase.GetCurrentMethod().Name is Test_GetCurrentMethod.
Actual behavior
Assert.Equal() Failure: Strings differ
Expected: "Test_GetCurrentMethod"
Actual: "GetCurrentMethod"
Regression?
Unknown; newly exposed by enabling the browser R2R library-test lane. Clean trimmed non-R2R execution passes. The failure also persists after correcting the unrelated CoreLib dynamic-code trimming substitution.
Known Workarounds
Quarantine only this method for browser R2R, preserving interpreter coverage.
Configuration
Browser-wasm CoreCLR Release, macOS arm64 build host, Chromium 153. Runtime native base 798449390515fa02f4b20160bedc5e34f8fbdfb9, with publishing prerequisite #133378 at 245cb70d593f2c8f3a4e23bcc422e7da5926e15b.
Other information
Possibly related to the duplicate-frame problem tracked in #133505 and the stack-walk changes in #133610. Those changes have not been tested against this reproduction, so this is not yet established as a duplicate.
Note
This issue was generated by GitHub Copilot from local test results and source inspection.
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Activity
lewing commentedon Sep 10, 2026
The same incorrect
GetCurrentMethodresult also appears inTest_GetCurrentMethod_Inlineable, and can corrupt expected values in unrelated attribute and exception tests. Those callers were not all failing in the first run.For the library-test bring-up, both dedicated
GetCurrentMethodtests are now browser-R2R-only ActiveIssues. Attribute tests andException_TargetSiteinstead obtain their explicitly known method viatypeof(...).GetMethod(nameof(...)), preserving their intended metadata/exception coverage rather than quarantining them. Searching for bothMethodBase.GetCurrentMethodand the inheritedMethodInfo.GetCurrentMethodspelling was necessary to cover all such uses in System.Runtime.Tests.The resulting full Runtime run reports 77,395 passed, 175 skipped, zero failed. The underlying R2R stack-walk bug is not fixed by these test changes.
Note
This update was generated by GitHub Copilot from local test results and source inspection.
[-][wasm][R2R] MethodBase.GetCurrentMethod returns GetCurrentMethod instead of the caller[/-][+][wasm][CoreCLR][R2R] MethodBase.GetCurrentMethod returns itself instead of its caller[/+]lewing commentedon Sep 10, 2026
This is an API conformance bug in CoreCLR, not a test expectation problem or missing trimming metadata.
MethodBase.GetCurrentMethod()must identify the method making the call; returning theGetCurrentMethodimplementation itself violates that contract.The existing failing test expects
Test_GetCurrentMethodbut receivesGetCurrentMethod. It passes in a clean trimmed interpreter build with the same aggressive trimming enabled. Explicit reflection lookup can retrieve the expected method and its attributes, so the metadata is present.The browser-R2R ActiveIssues and explicit method lookups used during library-test bring-up are temporary workarounds. They do not fix the runtime conformance defect or justify changing the API contract.
The WASM portable-entrypoint slow path retaining a
PrestubMethodFrameduring invocation is a leading explanation for the wrong caller, not a proven root cause. The related StackTrace change in #133610 has not been demonstrated to fixGetCurrentMethod.Corrected the area label from Mono to
area-VM-coreclr.Note
This clarification was generated by GitHub Copilot from the observed failures and source investigation.
dotnet-policy-service commentedon Sep 10, 2026
Tagging subscribers to this area: @agocke
See info in area-owners.md if you want to be subscribed.
lewing commentedon Sep 10, 2026
Update to the bring-up approach: the explicit method-lookup workarounds described above have been reverted. All seven affected attribute/exception test methods retain their original
GetCurrentMethod()calls and assertions, with browser-R2R-onlyActiveIssueannotations pointing here. Existing exclusions for other platforms, Mono, or aggressive trimming are unchanged.The conformance bug must be fixed in the runtime; changing these tests to avoid the affected API would weaken future regression coverage. Once fixed, the annotations can be removed and the original checks re-enabled.
The restored methods all execute and pass in the untrimmed browser interpreter control: 7 passed, zero skipped. The affected-class trimmed R2R run passes with the quarantines applied: 15 passed, 3 existing skips, zero failures.
Note
This update was generated by GitHub Copilot from the requested test changes and local execution results.
dotnet-policy-service commentedon Sep 11, 2026
Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.
[wasm] Fix caller identification across R2R prestub transitions (#133707
Re-enable WebAssembly caller-identification conformance tests
Re-enable WebAssembly caller-identification conformance tests