[release/11.0] [iOS] Avoid debugger patches in R2R code without dynamic code support - #134139
Merged
Merged
Conversation
…#133577) ## Description When CoreCLR runs an R2R + interpreter application on a physical iOS device, `DebuggerThreadStarter` can try to place a software breakpoint in signed R2R code. Making the page writable removes execute permission, and iOS does not allow the runtime to restore it. The process is then terminated with a code-signing invalid-page failure. This change prevents debugger patch activation in R2R code when `FEATURE_DYNAMIC_CODE_COMPILED` is disabled. It also: - propagates patch activation failure instead of reporting success; - removes or unbinds patches that cannot be activated; - keeps deferred R2R patches unbound; - cancels the pending `DebuggerThreadStarter` when interpreter entry sends the thread-start event directly; Breakpoints cannot be activated in R2R methods in this configuration. A direct breakpoint request fails with `CORDBG_E_UNABLE_TO_SET_BREAKPOINT`.
|
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. |
Contributor
|
Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag |
matouskozak
requested review from
anicka-net,
steveisok,
thaystg and
tommcdon
September 17, 2026 13:59
This was referenced Sep 17, 2026
tommcdon
approved these changes
Sep 18, 2026
steveisok
approved these changes
Sep 18, 2026
steveisok
added
Servicing-approved
Member
|
Hi, the code complete date for RC2 is Monday 21st September. Make sure to merge this PR on that date at the latest, or it won't make it into that release. As a reminder, if this is a product change, you also need Tactics approval before merging this PR (test-only or infra-only changes don't require Tactics approval). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport of #133577 to release/11.0
/cc @matouskozak
Customer Impact
The debugging on iOS physical devices doesn't work because debugger tries to put an internal breakpoint into the R2R images which triggers a code signing crash on iOS. This means that an iOS app cannot start in debug on physical devices. This PR prevents debugger attempts to put a patch into R2R code on platforms that are build with disabled dynamic code compilation. Currently, only iOS/tvOS are configurations which ship under CoreCLR with dynamic code compilation.
Regression
Testing
This was uncovered by CSI manual testing on physical iOS devices (https://devdiv.visualstudio.com/DevDiv/_workitems/edit/3027937). The fix was verified to work in both VS and VS Code debugger on physical iOS devices.
Risk
Low:
The biggest change (blocking patches on R2R code) is covered by
#ifndef FEATURE_DYNAMIC_CODE_COMPILEDthus shouldn't affect any other configuration that is supported under debugger. The rest of changes is around propagation of results in case theActivatePatchfalse.Note, this change can cause debugger issues on windows x64 if build without dynamic code compile as mentioned in #133577 (comment) but we don't ship that configuration anywhere currently.
IMPORTANT: If this backport is for a servicing release, please verify that:
release/X.0-staging, notrelease/X.0.release/X.0(no-stagingsuffix).Package authoring no longer needed in .NET 9
IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older versions.