Improve generated dump debugging instructions #46493
Conversation
|
I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label. |
|
These instructions assume that binaries and symbols are all in |
|
Tagging subscribers to this area: @ViktorHofer Issue DetailsIn the process of debugging a test crash, I used the new instructions and workflow -- which was great! I have tried to improve the instructions more
The only commands that can't be copied/pasted are where you need to type in the path to the dump you downloaded: as things are, the generator script doesn't know where the dumps will go, unfortunately. Example of new output: https://gist.github.com/danmosemsft/81023ec112f3c6d4db0e75a7b8a3b56a .. hopefully much quicker and easier to use. (@mikem8361 maybe you can scan it) I have tested the Windows steps. I need to find a Linux dump to test those instructions.
|
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
| @@ -759,7 +759,7 @@ phase-specific information by searching for the phase name. Some useful points f | |||
| You can enable dumps by setting the `COMPlus_JitDump` environment variable to a space-separated list of the method(s) | |||
| you want to dump. For example: | |||
|
|
|||
| ```cmd | |||
| ```bat | |||
There was a problem hiding this comment.
FYI both cmd and bat are correct. this change is not needed.
:: with ```cmd
setx FOO=BAR
echo %FOO%There was a problem hiding this comment.
fine I'll make them cmd consistently.
|
Hello @danmosemsft! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
|
Android timeout is https://github.com/dotnet/core-eng/issues/11797 |
| ``` | ||
| If prompted, open a new command prompt to pick up the updated PATH. | ||
| ```sh | ||
| dotnet sos install --architecture Arm |
There was a problem hiding this comment.
The last one will override the others, at least on Linux (not sure about windows, haven't seen if it is conditional on the bitness of the extension host, but given the errors I've seen I'd say no). Users should only install the one they are going to use.
There was a problem hiding this comment.
Oh - I didn't notice that because I was testing with x64, which is last!
Could we imagine installing them all, and picking the right one - eliminate another decision point? cc @mikem8361
There was a problem hiding this comment.
I'll fix the text meantime
There was a problem hiding this comment.
It looks like it defaults silently to the bitness of the dotnet.exe you're running it with (?)
There was a problem hiding this comment.
Yes it does default to the architecture of the dotnet.exe you are running (the most common case).
As far as installing all the of the architectures, there would have to be a rid named subdirectory to separate them so the decision point would be postponed a little to the .load command in windbg.
This manual dotnet-sos install/load on Windows was really meant as a fallback while we wait for the public debugger to include SOS (all architectures) like the internal one does now. The internal Windows debugger automatically loads the correct architecture and latest version of SOS from the extension gallery.
There was a problem hiding this comment.
Oh perfect then it will go away.
eng/testing/debug-dump-template.md
Outdated
|
|
||
| ## MacOS dumps | ||
| Instructions for debugging dumps on macOS are essentially the same as [Linux](#If-it's-a-Linux-dump-on-Linux...) with one exception: `dotnet-dump` cannot analyze macOS system dumps: you must use `lldb` for those. `dotnet-dump` can only analyze dumps created by `dotnet-dump` or `createdump` or by the runtime on hangs. |
There was a problem hiding this comment.
| Instructions for debugging dumps on macOS are essentially the same as [Linux](#If-it's-a-Linux-dump-on-Linux...) with one exception: `dotnet-dump` cannot analyze macOS system dumps: you must use `lldb` for those. `dotnet-dump` can only analyze dumps created by `dotnet-dump` or `createdump` or by the runtime on hangs. | |
| Instructions for debugging dumps on macOS are essentially the same as [Linux](#If-it's-a-Linux-dump-on-Linux...) with one exception: `dotnet-dump` cannot analyze macOS system dumps: you must use `lldb` for those. `dotnet-dump` can only analyze dumps created by `dotnet-dump` or `createdump`, by the runtime on crashes when the appropriate environment variables are set, or the [`blame-hang` setting of `dotnet test`](https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-test). |
ghost
locked as resolved and limited conversation to collaborators
In the process of debugging a test crash, I used the new instructions and workflow -- which was great!
I have tried to improve the instructions more
The only commands that can't be copied/pasted are where you need to type in the path to the dump you downloaded: as things are, the generator script doesn't know where the dumps will go, unfortunately.
Example of new output: https://gist.github.com/danmosemsft/81023ec112f3c6d4db0e75a7b8a3b56a .. hopefully much quicker and easier to use. (@mikem8361 maybe you can scan it)
I have tested the Windows steps. I need to find a Linux dump to test those instructions.