Skip to content
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

Merged
merged 2 commits into from
Sep 16, 2020
Merged

Conversation

mikem8361
Copy link
Member

Add ld (i.e. ld_2_23.so) interpreter program headers to Linux coredumps. This is important to the windbg linux support.

@ghost
Copy link

ghost commented Sep 12, 2020

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

@mikem8361
Copy link
Member Author

@janvorli ping?

@janvorli
Copy link
Member

@mikem8361 I am sorry, I've missed this PR.

Copy link
Member

@janvorli janvorli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thank you!

@mikem8361 mikem8361 merged commit 33dba95 into dotnet:master Sep 16, 2020
@mikem8361 mikem8361 deleted the createdumpfixes branch September 16, 2020 02:54
@mikem8361
Copy link
Member Author

/backport to release/5.0-rc2

@github-actions
Copy link
Contributor

Started backporting to release/5.0-rc2: https://github.com/dotnet/runtime/actions/runs/259774185

mikem8361 added a commit to mikem8361/runtime that referenced this pull request Sep 22, 2020
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.
mikem8361 added a commit that referenced this pull request Sep 22, 2020
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.
github-actions bot pushed a commit that referenced this pull request Sep 22, 2020
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.
mikem8361 added a commit that referenced this pull request Sep 22, 2020
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>
@ghost ghost locked as resolved and limited conversation to collaborators Dec 7, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants