Fix interpreter context after breakpoint#127480
Merged
janvorli merged 1 commit intodotnet:mainfrom Apr 28, 2026
Merged
Conversation
When debugger breakpoint is hit and then debugger resumes the execution, the context at which the breakpoint was hit can be modified. For example, one of the exception interception tests does that to continue from a different location after an exception is hit. The interpreter ignored changes in the context and resumed execution at the original breakpoint location instead of the modified context. This change fixes it by throwing the ResumeAfterCatchException if the context was modified. That ensures that we resume the exception correctly even if both the stack frame and the ip was changed. The ResumeAfterCatchException became a bit of a misnomer, but I don't want to pollute this PR by renaming the ResumeAfterCatchException to ResumeException, which would be a better name. I'd prefer doing it in a separate PR.
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes CoreCLR interpreter debugging behavior when resuming from an interpreter breakpoint after the debugger has modified the thread context (e.g., changing the resume IP and/or the interpreter frame). Instead of continuing at the original breakpoint location, the interpreter now detects the modified context and forces a resume using the existing ResumeAfterCatchException unwind/resume path.
Changes:
- Use the return value of
g_pDebugInterface->FirstChanceNativeException(...)to determine whether the debugger handled the breakpoint event. - Detect debugger modifications to the breakpoint
CONTEXT(IP and SP) after the callback returns. - If the context was modified, throw
ResumeAfterCatchException(viaThrowResumeAfterCatchException) to correctly unwind/resume interpreter execution at the updated location.
Member
Author
|
Hmm, it breaks another diagnostic test, I need to investigate it more. |
kotlarmilos
approved these changes
Apr 28, 2026
19 tasks
Member
Author
|
The issue I was seeing was actually unrelated, I had some extra change locally that was causing the other test break |
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.
When debugger breakpoint is hit and then debugger resumes the execution, the context at which the breakpoint was hit can be modified. For example, one of the exception interception tests does that to continue from a different location after an exception is hit. The interpreter ignored changes in the context and resumed execution at the original breakpoint location instead of the modified context.
This change fixes it by throwing the
ResumeAfterCatchExceptionif the context was modified. That ensures that we resume the exception correctly even if both the stack frame and the IP was changed. TheResumeAfterCatchExceptionbecame a bit of a misnomer, but I don't want to pollute this PR by renaming theResumeAfterCatchExceptiontoResumeException, which would be a better name now. I'd prefer doing it in a separate PR.Follow-up to #126576
This fixes the following interpreter debugger test failure: