Skip to content

Fix VS4Mac crash report and core dump generation perf problems #60205

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.

Sign up for GitHub

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

Merged
mikem8361 merged 5 commits into from
Oct 12, 2021
Merged

Fix VS4Mac crash report and core dump generation perf problems #60205

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
a14b23c
Refactor the DAC enumerate memory region phase out of gather crash info
Oct 8, 2021
e8bd4c0
Since on both Linux and MacOS all the RW regions have been already added
Oct 9, 2021
8eea698
Move current_c_gc_state out of !MULTIPLE_HEAPS
cshung Oct 10, 2021
96ee054
Code review feedback
Oct 11, 2021
f93a60e
Opt into fast heap dumps with COMPlus_DbgEnableFastHeapDumps=1 env va…
Oct 11, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Since on both Linux and MacOS all the RW regions have been already added 
by createdump itself for heap dumps, then the sometimes slow (4 minutes for
VS4Mac) heap enum memory region is changed to the faster normal one. It adds
necessary DAC globals, etc. without the costly assembly, module, class, type
runtime data structure enumeration.
  • Loading branch information
Mike McLaughlin committed Oct 12, 2021
commit e8bd4c0c0042738f8e57427ebe8636294f10bfc1
11 changes: 10 additions & 1 deletion src/coreclr/debug/createdump/crashinfo.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -280,9 +280,18 @@ CrashInfo::EnumerateMemoryRegionsWithDAC(MINIDUMP_TYPE minidumpType)
{
if (m_pClrDataEnumRegions != nullptr && (minidumpType & MiniDumpWithFullMemory) == 0)
{
// Calls CrashInfo::EnumMemoryRegion for each memory region found by the DAC
TRACE("EnumerateMemoryRegionsWithDAC: Memory enumeration STARTED\n");

// Since on both Linux and MacOS all the RW regions have been already added
// by createdump itself for heap dumps, then the sometimes slow (4 minutes for
// VS4Mac) heap enum memory region is changed to the faster normal one. It adds
// necessary DAC globals, etc. without the costly assembly, module, class, type
// runtime data structure enumeration.
if (minidumpType & MiniDumpWithPrivateReadWriteMemory)
{
minidumpType = MiniDumpNormal;
}
// Calls CrashInfo::EnumMemoryRegion for each memory region found by the DAC
HRESULT hr = m_pClrDataEnumRegions->EnumMemoryRegions(this, minidumpType, CLRDATA_ENUM_MEM_DEFAULT);
if (FAILED(hr))
{
Expand Down
1 change: 1 addition & 0 deletions src/coreclr/debug/daccess/enummem.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1597,6 +1597,7 @@ HRESULT ClrDataAccess::EnumMemoryRegionsWorkerSkinny(IN CLRDataEnumMemoryFlags f
//
// collect CLR static
CATCH_ALL_EXCEPT_RETHROW_COR_E_OPERATIONCANCELLED( status = EnumMemCLRStatic(flags); )
CATCH_ALL_EXCEPT_RETHROW_COR_E_OPERATIONCANCELLED( status = EnumMemCLRHeapCrticalStatic(flags); );

// Dump AppDomain-specific info needed for MiniDumpNormal.
CATCH_ALL_EXCEPT_RETHROW_COR_E_OPERATIONCANCELLED( status = EnumMemDumpAppDomainInfo(flags); )
Expand Down
6 changes: 4 additions & 2 deletions src/coreclr/debug/daccess/request_svr.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -122,8 +122,10 @@ ClrDataAccess::ServerGCHeapDetails(CLRDATA_ADDRESS heapAddr, DacpGcHeapDetails *

detailsData->lowest_address = PTR_CDADDR(g_lowest_address);
detailsData->highest_address = PTR_CDADDR(g_highest_address);
detailsData->current_c_gc_state = (CLRDATA_ADDRESS)*g_gcDacGlobals->current_c_gc_state;

if (g_gcDacGlobals->current_c_gc_state != NULL)
{
detailsData->current_c_gc_state = (CLRDATA_ADDRESS)*g_gcDacGlobals->current_c_gc_state;
Copy link
Member

@hoyosjs hoyosjs Oct 10, 2021

Choose a reason for hiding this comment

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

Should we try to poison this in the case the pointer is null? And did you find a case where this was true? It should only be true if BACKGROUND_GC is not true.

Copy link
Contributor Author

@mikem8361 mikem8361 Oct 10, 2021 •
edited by cshung
Loading

Choose a reason for hiding this comment

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

I attached to the WebApp debuggee process from the SOS tests (they were segfault'ing on this line) and the g_gcDacGlobals pointer was null. I'm not sure how this is happening unless BACKGROUND_GC is true like you said. The actual GC variable (gc_heap::current_c_gc_state) it is suppose to be pointing to was 2 (c_gc_state_free). I probably should set it to c_gc_state_free if it is null.

/cc: @Maoni0 @cshung do you have any clue why g_dacDacGlobals->current_c_gc_state isn't initialized?

Copy link
Contributor

@cshung cshung Oct 10, 2021 •
edited
Loading

Choose a reason for hiding this comment

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

It looks like I accidentally moved that into !MULTIPLE_HEAP so it fails for server GC. It should work now after I pushed the fix.

Copy link
Member

@janvorli janvorli Oct 11, 2021

Choose a reason for hiding this comment

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

Is the detailsData->current_c_gc_state initialized to NULL somewhere upstream so that it doesn't end up having a random valueif the condition is false?

Copy link
Contributor Author

@mikem8361 mikem8361 Oct 11, 2021

Choose a reason for hiding this comment

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

Yes, I'm going to push a change that initializes it to c_gc_state_free.

}
// now get information specific to this heap (server mode gives us several heaps; we're getting
// information about only one of them.
detailsData->alloc_allocated = (CLRDATA_ADDRESS)pHeap->alloc_allocated;
Expand Down