Uh oh!
There was an error while loading. Please reload this page.
Fix WASM R2R virtual IP initialization - #132172
Conversation
Register composite virtual IP ranges before eager fixups publish entry points, and assert that virtual IP bases are initialized before use. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: e77a1005-f20a-4fbd-9d4a-0a0b36f3a542
|
Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
There was a problem hiding this comment.
Pull request overview
This PR fixes a WASM ReadyToRun (R2R) initialization ordering issue where R2R entry points could be published before the composite virtual-IP (VIP) range was registered, causing later stack-walk lookups to miss those methods.
Changes:
- Ensures the WASM virtual-IP range is registered before eager fixups can publish entry points (and does so even when there are no eager import sections).
- Shares the assigned minimum virtual IP across composite components (single shared VIP base).
- Adds debug assertions to enforce that the minimum virtual IP is initialized before use.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/coreclr/vm/readytoruninfo.h | Adds WASM min-VIP storage on the composite core info and asserts min-VIP initialization before use. |
| src/coreclr/vm/readytoruninfo.cpp | Makes VIP registration idempotent and shares the computed min-VIP across composite components. |
| src/coreclr/vm/ceeload.cpp | Registers VIP ranges earlier (before eager fixups) and avoids early-return on WASM when there are no import sections. |
adamperlin
left a comment
There was a problem hiding this comment.
Is it possible to de-couple virtual IP range registration as a separate step and have it run before RunEagerFixups, or is that not really feasible?
davidwrighton
commented
Aug 12, 2026
@adamperlin EagerFixups is the location where we initialize all of the modules for this sort of thing. It doesn't make sense to do it anywhere else really. |
davidwrighton
commented
Aug 12, 2026
/ba-g Test Monitor failed, but tests passed. |
Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara |
Remove the b65423 and fieldlayout suppressions now that dotnet#132078 and dotnet#132172 fix their underlying CoreCLR browser failures. Retain the EventPipe, ContextualReflection, and Server GC exclusions that remain necessary on current main. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 808c6867-a1ea-4256-a003-46c17785ad04
) ## Summary - Gate exactly four EventPipe events-validation projects on CoreCLR browser because they use unsupported `Process.GetCurrentProcess` and Process/PID-based managed self-process `DiagnosticsClient` collection; browser diagnostics use JS/WebSocket clients instead. - Temporarily suppress the CoreCLR-browser `ContextualReflection` interpreter failure through its tracked #131925 ActiveIssue. - Clarify that Server GC is disabled on CoreCLR browser by design. - `b65423` and `readytorun/fieldlayout` are absent from this change: current main includes the underlying fixes from #132078 and #132172, and both restored tests now pass targeted browser validation. Related issues: #131321, #131898, #131925. ## Validation - Merged and validated current `origin/main` at `663c457b86ccd35743374676a69de5ed97bc3b14`; the Checked browser `clr+libs` baseline passed with 0 warnings and 0 errors. - `b65423` passed 3/3: browser default, browser `DOTNET_TieredCompilation=0`, and native macOS arm64 process-isolated execution, each with expected/actual exit code 100. - `fieldlayout` passed 2/2 in browser default and no-tiered modes after producing and loading its composite Crossgen2/R2R WASM image. - Removing the ContextualReflection ActiveIssue reproduced #131925 in 2/2 browser modes; the final gated browser runs passed 2/2, and native ContextualReflection executed successfully. - An ungated no-tiered `GCEvents` run reproduced the expected `Process.GetCurrentProcess` PlatformNotSupportedException; all four final EventPipe projects were gated from CoreCLR-browser builds. - 14/14 representative property evaluations matched the intended scope across CoreCLR browser, CoreCLR macOS, and browser Mono. - Final delta: exactly 6 files, 23 insertions, 3 deletions. `git diff --check origin/main..HEAD` passed. > [!NOTE] > This pull request description was generated by GitHub Copilot. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 808c6867-a1ea-4256-a003-46c17785ad04
Fixes#131924.
ReadyToRun entry points could be published during eager fixups before the composite WASM virtual-IP range was registered. Those methods were entered into the entry-point map without the virtual-IP base, causing later stack-walk lookups to miss them.
This change:
Validation:
build.cmd clr.runtime+clr.hosts -os browsersrc\tests\build.cmd skipmanaged browserreadytorun\fieldlayout\fieldlayout\fieldlayout.cmdNote
This pull request description was generated with GitHub Copilot.