-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
dotnet-gcdump and perfview's gcdump do not work on 5.0 runtimes #38639
Comments
Tagging subscribers to this area: @Maoni0 |
Tagging subscribers to this area: @tommcdon |
uh oh! Is it possible this can be tied back to the changes for the new Pinned Object Heap? GCHeapDumps work via callbacks while the GC walks the heap. If the events changed or format of the type info changed, it is quite possible the GCHeapDump event parsing logic is failing to map type info to events in the stream. I don't have immediate bandwidth to triage this, but I'll take a look hopefully later this week. |
It is possible it is caused by Pinned Heap, although I do not recall if events changed for this. |
I looked a little bit and it seems that BulkType events are not being fired. Here is a log from perfview, BulkTypeEventCount:0 and BulkNodeEventCount:1 seems very suspicious.
|
Hmm that looks like the behavior from 3.0 where the type system wasn't being flushed so the events were never firing. dotnet/coreclr#26270 fixed that in the 3.1 timeframe. Next week I'll take a look under a debugger and see if I can find anything. |
@davmason thanks for fixing this! |
If you collect a gc dump with either dotnet-gcump or perfview's gcdump command from a live process you will see output like this:
It works on 3.1 but fails on 5.0 runtimes. Since both tools are failing I suspect it is a runtime issue where we're not emitting the right events.
The text was updated successfully, but these errors were encountered: