Native frames missing crashreport.json #63309
Comments
|
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
dotnet-issue-labeler
bot
added
the
untriaged
mikem8361
added
area-Diagnostics-coreclr
and removed
untriaged
|
Tagging subscribers to this area: @tommcdon Issue DetailsDescriptionThe crashreport.json file seems to be missing all native frames up until the first managed frame, except for the very first one, which is missing the
Reproduction StepsEnabled the core dump, and the crash report, and induce a crash. Compare the json with what you see in LLDB with Expected behaviorAll stack frames should be in the json report. Actual behaviorMissing frames. Regression?No response Known WorkaroundsNo response ConfigurationNo response Other informationNo response
|
|
@mikem8361 I also just noticed, if you look at the first frame in the json, it's tagged |
mikem8361
added a commit
to mikem8361/runtime
that referenced
this issue
Jan 13, 2022
The wrong module was being passed to the remote unwinder because the load bias for shared modules was being calculated incorrectly. Issue: dotnet#63309
jeffschwMSFT
pushed a commit
that referenced
this issue
Jan 13, 2022
* Fix the MacOS remote unwinder for VS4Mac The wrong module was being passed to the remote unwinder because the load bias for shared modules was being calculated incorrectly. Issue: #63309 * Fix native frame unwind in syscall on arm64 for VS4Mac crash report From PR in main: #63598 Add arm64 version of StepWithCompactNoEncoding for syscall leaf node wrappers that have compact encoding of 0. Fix ReadCompactEncodingRegister so it actually decrements the addr. Change StepWithCompactEncodingArm64 to match what MacOS libunwind does for framed and frameless stepping. arm64 can have frames with the same SP (but different IPs). Increment SP for this condition so createdump's unwind loop doesn't break out on the "SP not increasing" check and the frames are added to the thread frame list in the correct order. Add getting the unwind info for tail called functions like this: __ZL14PROCEndProcessPvji: 36630: f6 57 bd a9 stp x22, x21, [sp, #-48]! 36634: f4 4f 01 a9 stp x20, x19, [sp, #16] 36638: fd 7b 02 a9 stp x29, x30, [sp, #32] 3663c: fd 83 00 91 add x29, sp, #32 ... 367ac: e9 01 80 52 mov w9, #15 367b0: 7f 3e 02 71 cmp w19, #143 367b4: 20 01 88 1a csel w0, w9, w8, eq 367b8: 2e 00 00 94 bl _PROCAbort _TerminateProcess: -> 367bc: 22 00 80 52 mov w2, #1 367c0: 9c ff ff 17 b __ZL14PROCEndProcessPvji The IP (367bc) returns the (incorrect) frameless encoding with nothing on the stack (uses an incorrect LR to unwind). To fix this get the unwind info for PC -1 which points to PROCEndProcess with the correct unwind info. This matches how lldb unwinds this frame. Always address module segment to IP lookup list instead of checking the module regions. Strip pointer authentication bits on PC/LR.
github-actions bot
pushed a commit
that referenced
this issue
Jan 13, 2022
The wrong module was being passed to the remote unwinder because the load bias for shared modules was being calculated incorrectly. Issue: #63309
safern
pushed a commit
that referenced
this issue
Jan 13, 2022
* Fix the MacOS remote unwinder for VS4Mac The wrong module was being passed to the remote unwinder because the load bias for shared modules was being calculated incorrectly. Issue: #63309 * Fix native frame unwind in syscall on arm64 for VS4Mac crash report From PR in main: #63598 Add arm64 version of StepWithCompactNoEncoding for syscall leaf node wrappers that have compact encoding of 0. Fix ReadCompactEncodingRegister so it actually decrements the addr. Change StepWithCompactEncodingArm64 to match what MacOS libunwind does for framed and frameless stepping. arm64 can have frames with the same SP (but different IPs). Increment SP for this condition so createdump's unwind loop doesn't break out on the "SP not increasing" check and the frames are added to the thread frame list in the correct order. Add getting the unwind info for tail called functions like this: __ZL14PROCEndProcessPvji: 36630: f6 57 bd a9 stp x22, x21, [sp, #-48]! 36634: f4 4f 01 a9 stp x20, x19, [sp, #16] 36638: fd 7b 02 a9 stp x29, x30, [sp, #32] 3663c: fd 83 00 91 add x29, sp, #32 ... 367ac: e9 01 80 52 mov w9, #15 367b0: 7f 3e 02 71 cmp w19, #143 367b4: 20 01 88 1a csel w0, w9, w8, eq 367b8: 2e 00 00 94 bl _PROCAbort _TerminateProcess: -> 367bc: 22 00 80 52 mov w2, #1 367c0: 9c ff ff 17 b __ZL14PROCEndProcessPvji The IP (367bc) returns the (incorrect) frameless encoding with nothing on the stack (uses an incorrect LR to unwind). To fix this get the unwind info for PC -1 which points to PROCEndProcess with the correct unwind info. This matches how lldb unwinds this frame. Always address module segment to IP lookup list instead of checking the module regions. Strip pointer authentication bits on PC/LR. Co-authored-by: Mike McLaughlin <mikem@microsoft.com>
|
This has been fixed in main/6.0 now. |
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Description
The crashreport.json file seems to be missing all native frames up until the first managed frame, except for the very first one, which is missing the
unmanaged_namefield.Reproduction Steps
Enabled the core dump, and the crash report, and induce a crash. Compare the json with what you see in LLDB with
clrstack -f.Expected behavior
All stack frames should be in the json report.
Actual behavior
Missing frames.
Regression?
Yes, introduced with this PR #60995
Known Workarounds
None
The text was updated successfully, but these errors were encountered: