Fix x64 data breakpoint handling after CORINFO_HELP_ARRADDR_ST inlining#127251
Merged
tommcdon merged 3 commits intodotnet:mainfrom Apr 23, 2026
Merged
Fix x64 data breakpoint handling after CORINFO_HELP_ARRADDR_ST inlining#127251tommcdon merged 3 commits intodotnet:mainfrom
tommcdon merged 3 commits intodotnet:mainfrom
Conversation
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Fixes x64 data breakpoint unwind behavior after CORINFO_HELP_ARRADDR_ST inlining changed the write barrier call path, so the debugger unwinds back to user code instead of stopping in CastHelpers frames.
Changes:
- Extends the x64
FEATURE_DATABREAKPOINTunwind logic to keep unwinding pastCastHelpers-owned managed frames after unwinding out of the native write barrier. - Identifies
CastHelpersframes via the owningMethodTableto remain stable across tiered compilation.
jkotas
reviewed
Apr 21, 2026
Member
|
@EgorBo FYI |
This reverts commit 184fca9.
This was referenced Apr 22, 2026
Open
TriggerDataBreakpoint plants a deferred native patch when a data breakpoint fires inside a write barrier. The patch was created with GetFP() (the base pointer register), but MatchPatch computes frame pointers via GetRegdisplayStackMark which uses SP on AMD64 and PCTAddr on x86. This mismatch caused MatchPatch to reject the patch, so the deferred data breakpoint never fired. Fix by using LEAF_MOST_FRAME to bypass the frame pointer check in MatchPatch. This is safe because the patch is thread-bound (MatchPatch validates the thread) and is a one-shot patch, so the recursive false-match scenario the frame check guards against does not apply. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
jkotas
approved these changes
Apr 22, 2026
This was referenced Apr 23, 2026
Member
Author
|
/ba-g failures are unrelated |
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
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.
After #126547, the WriteBarrier FCall was converted from native (FCall) to managed. This affected the debugger's unwind logic for data breakpoint handling (AdjustContextForJITHelpersForDebugger) resulting in the debugger to unwind into the JIT helper (CastHelpers.StelemRef) rather than user code.
The fix adds a loop after the initial unwind that checks whether the landed-on frame belongs to the CastHelpers
class and continues unwinding until it reaches user code. This only affects x64 data breakpoints, as x86 does a raw single-frame stack pop (restores EIP from ESP) rather than VirtualUnwindToFirstManagedCallFrame, so it was unaffected. ARM64 does not support data breakpoints.