ghost
commented
3 years ago Tagging subscribers to this area: @tommcdon See info in area-owners.md if you want to be subscribed.
Issue Details
_This issue has been moved from [a ticket on Developer Community](https://developercommunity.visualstudio.com/t/debug-dump-analyze-for-gen2loh/1355270)._ --- With debug-dump analyze, it's not clear how to ask for all the objects in the gen2 or LOH heap. dotnet-counters shows me gen2 is huge (and LOH not much better). So I dumpheap -stat and look for high counts in hope that's a proxy for gen2 (which for string types is iffy). While dotnet-counters shows I have high LOH, I don't think dumpheap TotalSize / Count is how I should find them, and if it were, it still takes pasting into Excel to compute. MSDN examples show a progression of 'dumpheap -stat', 'dumpheap -mt', 'gcroot'. Thankfully the first is reasonably sorted. The -mt though spews thousands of unsorted (w.r.t. my goal) lines, so I randomly pick some addresses from there and hope for the best. We have 8 heaps, hence 8 gen2 ranges, so it's hard to tell which objects to pick. Does dumpheap take 8 pairs of start-end address-ranges to filter within (vs. a -gen2 switch)? Finally, gcroot takes forever then spews 400 lines in the lineage, while typically I just need the last dozen (but sometimes patience is rewarded and I see an un-hooked event callback). If I could "| head" or "| tail", perhaps. Probably copying the dump off prod (Linux) to my devbox (Windows), I could bring to bear higher-level tools, except I have problems resolving any symbols. We shipped the pdbs, not sure why the dump didn't pre-resolve them, such an option didn't appear in 'dotent-dump collect --help'. I feel like the tools should guess looking for a leak is a common goal, yet the resource-centric operations are a bit cumbersome toward that goal. Not sure if this is a tool bug or a doc bug, but is there anything that can be done to make this simpler or easier to discover? --- ### Original Comments #### Feedback Bot on 3/2/2021, 10:26 PM:
We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.
#### Feedback Bot on 3/10/2021, 06:32 PM:This issue is currently being investigated. Our team will get back to you if either more information is needed, a workaround is available, or the issue is resolved.
--- ### Original Solutions (no solutions)| Author: | vsfeedback |
|---|---|
| Assignees: | - |
| Labels: | `area-Diagnostics-coreclr`, `untriaged` |
| Milestone: | - |
cshung
This issue has been moved from a ticket on Developer Community.
With debug-dump analyze, it's not clear how to ask for all the objects in the gen2 or LOH heap. dotnet-counters shows me gen2 is huge (and LOH not much better). So I dumpheap -stat and look for high counts in hope that's a proxy for gen2 (which for string types is iffy).
While dotnet-counters shows I have high LOH, I don't think dumpheap TotalSize / Count is how I should find them, and if it were, it still takes pasting into Excel to compute.
MSDN examples show a progression of 'dumpheap -stat', 'dumpheap -mt', 'gcroot'. Thankfully the first is reasonably sorted. The -mt though spews thousands of unsorted (w.r.t. my goal) lines, so I randomly pick some addresses from there and hope for the best. We have 8 heaps, hence 8 gen2 ranges, so it's hard to tell which objects to pick. Does dumpheap take 8 pairs of start-end address-ranges to filter within (vs. a -gen2 switch)? Finally, gcroot takes forever then spews 400 lines in the lineage, while typically I just need the last dozen (but sometimes patience is rewarded and I see an un-hooked event callback). If I could "| head" or "| tail", perhaps.
Probably copying the dump off prod (Linux) to my devbox (Windows), I could bring to bear higher-level tools, except I have problems resolving any symbols. We shipped the pdbs, not sure why the dump didn't pre-resolve them, such an option didn't appear in 'dotent-dump collect --help'.
I feel like the tools should guess looking for a leak is a common goal, yet the resource-centric operations are a bit cumbersome toward that goal. Not sure if this is a tool bug or a doc bug, but is there anything that can be done to make this simpler or easier to discover?
Original Comments
Feedback Bot on 3/2/2021, 10:26 PM:
We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.
Feedback Bot on 3/10/2021, 06:32 PM:
This issue is currently being investigated. Our team will get back to you if either more information is needed, a workaround is available, or the issue is resolved.
Original Solutions
(no solutions)