[Diagnostics] Avoid resolving IL offsets for framed crash frames - #131481
Open
mdh1418 wants to merge 2 commits into
Open
[Diagnostics] Avoid resolving IL offsets for framed crash frames#131481mdh1418 wants to merge 2 commits into
mdh1418 wants to merge 2 commits into
Conversation
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 4e8cbca3-06b0-4e48-9159-71608830cb0d
|
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: @agocke |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR tightens in-proc crash reporter stack-walk frame processing so native and IL offset resolution is only attempted when the CrawlFrame represents non-faulted, frameless managed code, avoiding offset-resolution asserts for framed transition/crash frames.
Changes:
- Introduces a single gate (
hasManagedNativeCode) to decide whetherGetRelOffset()is safe/meaningful for the current frame. - Uses the same gate to skip
GetILOffsetFromNative(...)for frames that don’t represent JIT-managed code at the current IP.
jkotas
reviewed
Jul 29, 2026
| @@ -260,7 +260,8 @@ FrameCallbackAdapter( | |||
|
|
|||
| Module* pModule = pMD->GetModule(); | |||
|
|
|||
| uint32_t nativeOffset = (pCF->HasFaulted() || !pCF->IsFrameless()) ? 0 : pCF->GetRelOffset(); | |||
| bool canResolveOffsets = !pCF->HasFaulted() && pCF->IsFrameless(); | |||
Member
There was a problem hiding this comment.
Why are we skipping the offset resolution for HasFaulted?
I would expect that we can resolve the offset for any frameless method (ie method that has valid EECodeInfo).
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.
FIxes 131517
#131273 avoided calling CrawlFrame::GetRelOffset() for framed crash-report stack frames. However, the reporter still attempted to resolve an IL offset for those frames.
A native SIGSEGV during a managed P/Invoke transition produced a framed CrawlFrame where:
• the MethodDesc represented the managed P/Invoke method;
• the instruction pointer was inside the native function that faulted.
Passing that pair to GetILOffsetFromNative triggered this Checked-build assertion:
g_pEEInterface->GetNativeCodeMethodDesc(startAddr) == fdThis change only resolves native and IL offsets for non-faulted, frameless frames whose instruction pointer represents JIT-generated managed code. Framed transition frames still retain their method, module, and token information, but report an IL offset of zero.
Testing
Validated real macOS arm64 in-proc crash reports in both Checked and Release builds, including a native SIGSEGV triggered through P/Invoke.