-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix createdump Windows triage dumps #42159
Conversation
…ps. This is important to the windbg linux support.
Tagging subscribers to this area: @tommcdon |
@janvorli ping? |
@mikem8361 I am sorry, I've missed this PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thank you!
/backport to release/5.0-rc2 |
Started backporting to release/5.0-rc2: https://github.com/dotnet/runtime/actions/runs/259774185 |
The stack unwinding in createdump was looping forever on the same IP (different SP) when it was attempting to unwind a frame that was in the ld module (typically libld*.so or on alpine ld-musl-x86_64.so). The ld module on Alpine doesn't having any unwind info (GNU_EH_FRAME empty) causing the libunwind code to loop on the same IP. This was caused by a recent change in PR dotnet#42159 to createdump that included the ld in the coredump. Createdump wouldn't attempt to unwind IPs in the ld module because it wasn't added to the module lookup list. Including the ld module is important to the windbg linux support so it will have to be revisited in 6.0 by changing the remote unwinder to handle this case of the Alpine ld module.
The stack unwinding in createdump was looping forever on the same IP (different SP) when it was attempting to unwind a frame that was in the ld module (typically libld*.so or on alpine ld-musl-x86_64.so). The ld module on Alpine doesn't having any unwind info (GNU_EH_FRAME empty) causing the libunwind code to loop on the same IP. This was caused by a recent change in PR #42159 to createdump that included the ld in the coredump. Createdump wouldn't attempt to unwind IPs in the ld module because it wasn't added to the module lookup list. Including the ld module is important to the windbg linux support so it will have to be revisited in 6.0 by changing the remote unwinder to handle this case of the Alpine ld module.
The stack unwinding in createdump was looping forever on the same IP (different SP) when it was attempting to unwind a frame that was in the ld module (typically libld*.so or on alpine ld-musl-x86_64.so). The ld module on Alpine doesn't having any unwind info (GNU_EH_FRAME empty) causing the libunwind code to loop on the same IP. This was caused by a recent change in PR #42159 to createdump that included the ld in the coredump. Createdump wouldn't attempt to unwind IPs in the ld module because it wasn't added to the module lookup list. Including the ld module is important to the windbg linux support so it will have to be revisited in 6.0 by changing the remote unwinder to handle this case of the Alpine ld module.
The stack unwinding in createdump was looping forever on the same IP (different SP) when it was attempting to unwind a frame that was in the ld module (typically libld*.so or on alpine ld-musl-x86_64.so). The ld module on Alpine doesn't having any unwind info (GNU_EH_FRAME empty) causing the libunwind code to loop on the same IP. This was caused by a recent change in PR #42159 to createdump that included the ld in the coredump. Createdump wouldn't attempt to unwind IPs in the ld module because it wasn't added to the module lookup list. Including the ld module is important to the windbg linux support so it will have to be revisited in 6.0 by changing the remote unwinder to handle this case of the Alpine ld module. Co-authored-by: Mike McLaughlin <mikem@microsoft.com>
Add ld (i.e. ld_2_23.so) interpreter program headers to Linux coredumps. This is important to the windbg linux support.