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

Linux "minidumps" don't have all the metadata necessary to display stack functions #56

Closed
mikem8361 opened this issue Aug 2, 2018 · 5 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@mikem8361
Copy link
Member

Both Windows and Linux minidumps don't save all the assemblies' metadata which can cause stack traces to display !Unknown. On Windows most debuggers like Windbg and VS can load the module from file for this kind of dumps. On Linux lldb/SOS doesn't load the native modules and really doesn't know anything about the managed assemblies.

There is an metadata provider interface that could be used to fix this for SOS on Linux.

@mikem8361 mikem8361 added the enhancement New feature or request label Aug 2, 2018
@mikem8361 mikem8361 added this to the Future milestone Aug 2, 2018
@mikem8361 mikem8361 self-assigned this Aug 2, 2018
@mikem8361
Copy link
Member Author

The interfaces to look at are:

ICLRMetadataLocator
ICorDebugMetadataLocator

Check out daccess.cpp:~6661

void *
ClrDataAccess::GetMetaDataFromHost(PEFile* peFile,
bool* isAlternate)

@patricksuo
Copy link

@mikem8361 do you know of a workaround ?

I have broken stack trace like this:

(lldb) sos PrintException
Exception object: 00007f03301b0a80
Exception type:   System.ArgumentNullException
Message:          Value cannot be null.
InnerException:   <none>
StackTrace (generated):
    SP               IP               Function
    00007FFE38E0DFA0 00007F03492E28EA StackExchange.Redis.dll!Unknown+0x7a
    00007FFE38E0DFD0 00007F03492E2836 StackExchange.Redis.dll!Unknown+0x16
    00007FFE38E0DFF0 00007F03492E1E4D SceneServer.dll!Unknown+0x14d
    00007FFE38E0E080 00007F03492DFF50 SceneServer.dll!Unknown+0x150
    00007FFE38E0E100 00007F03484F445E SceneServer.dll!Unknown+0xae
    00007FFE38E0E160 00007F03484D17C0 SceneServer.dll!Unknown+0x130

StackTraceString: <none>
HResult: 80004003

@mikem8361
Copy link
Member Author

The workaround for now is to create a full dump (-u or --full createdump option or setting COMPlus_DbgMiniDumpType=4).

@mikem8361
Copy link
Member Author

Ultimately it would be better to wait until issue #1 has been implemented and use the downloader to get the assembly metadata that is missing from a core dump inside the ICLRMetadataLocator implementation in SOS.

But until #1 is finished, we could add command to set a search path to look for the matching assemblies in the ICLRMetadataLocator callback. Not sure when this could be scheduled though.

@mikem8361 mikem8361 modified the milestones: Future, v3.0 Feb 8, 2019
mikem8361 added a commit to mikem8361/diagnostics that referenced this issue Mar 1, 2019
Issue #dotnet#56

Both Windows and Linux minidumps don't save all the assemblies' metadata which can cause
stack traces to display !Unknown. On Windows most debuggers like Windbg and VS can load
the module from file for this kind of dumps. On Linux lldb/SOS doesn't load the native
modules and really doesn't know anything about the managed assemblies.

Add metadata callback to datatarget and it's implementation in SOS.NETCore.
mikem8361 added a commit to mikem8361/diagnostics that referenced this issue Mar 1, 2019
Issue #dotnet#56

Both Windows and Linux minidumps don't save all the assemblies' metadata which can cause
stack traces to display !Unknown. On Windows most debuggers like Windbg and VS can load
the module from file for this kind of dumps. On Linux lldb/SOS doesn't load the native
modules and really doesn't know anything about the managed assemblies.

Add metadata callback to datatarget and it's implementation in SOS.NETCore.
mikem8361 added a commit to mikem8361/diagnostics that referenced this issue Mar 1, 2019
Issue #dotnet#56

Both Windows and Linux minidumps don't save all the assemblies' metadata which can cause
stack traces to display !Unknown. On Windows most debuggers like Windbg and VS can load
the module from file for this kind of dumps. On Linux lldb/SOS doesn't load the native
modules and really doesn't know anything about the managed assemblies.

Add metadata callback to datatarget and it's implementation in SOS.NETCore.
mikem8361 added a commit to mikem8361/diagnostics that referenced this issue Mar 1, 2019
Issue #dotnet#56

Both Windows and Linux minidumps don't save all the assemblies' metadata which can cause
stack traces to display !Unknown. On Windows most debuggers like Windbg and VS can load
the module from file for this kind of dumps. On Linux lldb/SOS doesn't load the native
modules and really doesn't know anything about the managed assemblies.

Add metadata callback to datatarget and it's implementation in SOS.NETCore.
mikem8361 added a commit to mikem8361/diagnostics that referenced this issue Mar 7, 2019
Issue #dotnet#56

Both Windows and Linux minidumps don't save all the assemblies' metadata which can cause
stack traces to display !Unknown. On Windows most debuggers like Windbg and VS can load
the module from file for this kind of dumps. On Linux lldb/SOS doesn't load the native
modules and really doesn't know anything about the managed assemblies.

Add metadata callback to datatarget and it's implementation in SOS.NETCore.
mikem8361 added a commit to mikem8361/diagnostics that referenced this issue Mar 14, 2019
Issue #dotnet#56

Both Windows and Linux minidumps don't save all the assemblies' metadata which can cause
stack traces to display !Unknown. On Windows most debuggers like Windbg and VS can load
the module from file for this kind of dumps. On Linux lldb/SOS doesn't load the native
modules and really doesn't know anything about the managed assemblies.

Add metadata callback to datatarget and it's implementation in SOS.NETCore.
mikem8361 added a commit to mikem8361/diagnostics that referenced this issue Mar 15, 2019
Issue #dotnet#56

Both Windows and Linux minidumps don't save all the assemblies' metadata which can cause
stack traces to display !Unknown. On Windows most debuggers like Windbg and VS can load
the module from file for this kind of dumps. On Linux lldb/SOS doesn't load the native
modules and really doesn't know anything about the managed assemblies.

Add metadata callback to datatarget and it's implementation in SOS.NETCore.
mikem8361 added a commit to mikem8361/diagnostics that referenced this issue Mar 16, 2019
Issue #dotnet#56

Both Windows and Linux minidumps don't save all the assemblies' metadata which can cause
stack traces to display !Unknown. On Windows most debuggers like Windbg and VS can load
the module from file for this kind of dumps. On Linux lldb/SOS doesn't load the native
modules and really doesn't know anything about the managed assemblies.

Add metadata callback to datatarget and it's implementation in SOS.NETCore.
mikem8361 added a commit to mikem8361/diagnostics that referenced this issue Mar 20, 2019
Issue #dotnet#56

Both Windows and Linux minidumps don't save all the assemblies' metadata which can cause
stack traces to display !Unknown. On Windows most debuggers like Windbg and VS can load
the module from file for this kind of dumps. On Linux lldb/SOS doesn't load the native
modules and really doesn't know anything about the managed assemblies.

Add metadata callback to datatarget and it's implementation in SOS.NETCore.
mikem8361 added a commit to mikem8361/diagnostics that referenced this issue Mar 20, 2019
Issue #dotnet#56

Both Windows and Linux minidumps don't save all the assemblies' metadata which can cause
stack traces to display !Unknown. On Windows most debuggers like Windbg and VS can load
the module from file for this kind of dumps. On Linux lldb/SOS doesn't load the native
modules and really doesn't know anything about the managed assemblies.

Add metadata callback to datatarget and it's implementation in SOS.NETCore.
mikem8361 added a commit to mikem8361/diagnostics that referenced this issue Apr 17, 2019
Issue #dotnet#56

Both Windows and Linux minidumps don't save all the assemblies' metadata which can cause
stack traces to display !Unknown. On Windows most debuggers like Windbg and VS can load
the module from file for this kind of dumps. On Linux lldb/SOS doesn't load the native
modules and really doesn't know anything about the managed assemblies.

Add metadata callback to datatarget and it's implementation in SOS.NETCore.
mikem8361 added a commit to mikem8361/diagnostics that referenced this issue Apr 17, 2019
Issue #dotnet#56

Both Windows and Linux minidumps don't save all the assemblies' metadata which can cause
stack traces to display !Unknown. On Windows most debuggers like Windbg and VS can load
the module from file for this kind of dumps. On Linux lldb/SOS doesn't load the native
modules and really doesn't know anything about the managed assemblies.

Add metadata callback to datatarget and it's implementation in SOS.NETCore.
mikem8361 added a commit to mikem8361/diagnostics that referenced this issue Apr 18, 2019
Issue #dotnet#56

Both Windows and Linux minidumps don't save all the assemblies' metadata which can cause
stack traces to display !Unknown. On Windows most debuggers like Windbg and VS can load
the module from file for this kind of dumps. On Linux lldb/SOS doesn't load the native
modules and really doesn't know anything about the managed assemblies.

Add metadata callback to datatarget and it's implementation in SOS.NETCore.
mikem8361 added a commit to mikem8361/diagnostics that referenced this issue Apr 18, 2019
Issue #dotnet#56

Both Windows and Linux minidumps don't save all the assemblies' metadata which can cause
stack traces to display !Unknown. On Windows most debuggers like Windbg and VS can load
the module from file for this kind of dumps. On Linux lldb/SOS doesn't load the native
modules and really doesn't know anything about the managed assemblies.

Add metadata callback to datatarget and it's implementation in SOS.NETCore.
mikem8361 added a commit to mikem8361/diagnostics that referenced this issue Apr 22, 2019
Issue #dotnet#56

Both Windows and Linux minidumps don't save all the assemblies' metadata which can cause
stack traces to display !Unknown. On Windows most debuggers like Windbg and VS can load
the module from file for this kind of dumps. On Linux lldb/SOS doesn't load the native
modules and really doesn't know anything about the managed assemblies.

Add metadata callback to datatarget and it's implementation in SOS.NETCore.
mikem8361 added a commit to mikem8361/diagnostics that referenced this issue Apr 23, 2019
Issue #dotnet#56

Both Windows and Linux minidumps don't save all the assemblies' metadata which can cause
stack traces to display !Unknown. On Windows most debuggers like Windbg and VS can load
the module from file for this kind of dumps. On Linux lldb/SOS doesn't load the native
modules and really doesn't know anything about the managed assemblies.

Add metadata callback to datatarget and it's implementation in SOS.NETCore.
mikem8361 added a commit to mikem8361/diagnostics that referenced this issue Apr 23, 2019
Issue #dotnet#56

Both Windows and Linux minidumps don't save all the assemblies' metadata which can cause
stack traces to display !Unknown. On Windows most debuggers like Windbg and VS can load
the module from file for this kind of dumps. On Linux lldb/SOS doesn't load the native
modules and really doesn't know anything about the managed assemblies.

Add metadata callback to datatarget and it's implementation in SOS.NETCore.
mikem8361 added a commit to mikem8361/diagnostics that referenced this issue Apr 24, 2019
Issue #dotnet#56

Both Windows and Linux minidumps don't save all the assemblies' metadata which can cause
stack traces to display !Unknown. On Windows most debuggers like Windbg and VS can load
the module from file for this kind of dumps. On Linux lldb/SOS doesn't load the native
modules and really doesn't know anything about the managed assemblies.

Add metadata callback to datatarget and it's implementation in SOS.NETCore.
mikem8361 added a commit to mikem8361/diagnostics that referenced this issue Apr 27, 2019
Issue #dotnet#56

Both Windows and Linux minidumps don't save all the assemblies' metadata which can cause
stack traces to display !Unknown. On Windows most debuggers like Windbg and VS can load
the module from file for this kind of dumps. On Linux lldb/SOS doesn't load the native
modules and really doesn't know anything about the managed assemblies.

Add metadata callback to datatarget and it's implementation in SOS.NETCore.
mikem8361 added a commit to mikem8361/diagnostics that referenced this issue Apr 27, 2019
Issue #dotnet#56

Both Windows and Linux minidumps don't save all the assemblies' metadata which can cause
stack traces to display !Unknown. On Windows most debuggers like Windbg and VS can load
the module from file for this kind of dumps. On Linux lldb/SOS doesn't load the native
modules and really doesn't know anything about the managed assemblies.

Add metadata callback to datatarget and it's implementation in SOS.NETCore.
mikem8361 added a commit to mikem8361/diagnostics that referenced this issue Apr 27, 2019
Issue #dotnet#56

Both Windows and Linux minidumps don't save all the assemblies' metadata which can cause
stack traces to display !Unknown. On Windows most debuggers like Windbg and VS can load
the module from file for this kind of dumps. On Linux lldb/SOS doesn't load the native
modules and really doesn't know anything about the managed assemblies.

Add metadata callback to datatarget and it's implementation in SOS.NETCore.
mikem8361 added a commit to mikem8361/diagnostics that referenced this issue Apr 28, 2019
Issue #dotnet#56

Both Windows and Linux minidumps don't save all the assemblies' metadata which can cause
stack traces to display !Unknown. On Windows most debuggers like Windbg and VS can load
the module from file for this kind of dumps. On Linux lldb/SOS doesn't load the native
modules and really doesn't know anything about the managed assemblies.

Add metadata callback to datatarget and it's implementation in SOS.NETCore.
mikem8361 added a commit to mikem8361/diagnostics that referenced this issue Apr 30, 2019
Issue #dotnet#56

Both Windows and Linux minidumps don't save all the assemblies' metadata which can cause
stack traces to display !Unknown. On Windows most debuggers like Windbg and VS can load
the module from file for this kind of dumps. On Linux lldb/SOS doesn't load the native
modules and really doesn't know anything about the managed assemblies.

Add metadata callback to datatarget and it's implementation in SOS.NETCore.

Add IsMetadataMemory() and the metadata region list. This is because lldb on core dumps
returns 0's on missing metadata memory reads instead of an error.
mikem8361 added a commit to mikem8361/diagnostics that referenced this issue Apr 30, 2019
Issue #dotnet#56

Both Windows and Linux minidumps don't save all the assemblies' metadata which can cause
stack traces to display !Unknown. On Windows most debuggers like Windbg and VS can load
the module from file for this kind of dumps. On Linux lldb/SOS doesn't load the native
modules and really doesn't know anything about the managed assemblies.

Add metadata callback to datatarget and it's implementation in SOS.NETCore.

Add IsMetadataMemory() and the metadata region list. This is because lldb on core dumps
returns 0's on missing metadata memory reads instead of an error.
mikem8361 added a commit to mikem8361/diagnostics that referenced this issue Apr 30, 2019
Issue #dotnet#56

Both Windows and Linux minidumps don't save all the assemblies' metadata which can cause
stack traces to display !Unknown. On Windows most debuggers like Windbg and VS can load
the module from file for this kind of dumps. On Linux lldb/SOS doesn't load the native
modules and really doesn't know anything about the managed assemblies.

Add metadata callback to datatarget and it's implementation in SOS.NETCore.

Add IsMetadataMemory() and the metadata region list. This is because lldb on core dumps
returns 0's on missing metadata memory reads instead of an error.
mikem8361 added a commit to mikem8361/diagnostics that referenced this issue May 1, 2019
Issue #dotnet#56

Both Windows and Linux minidumps don't save all the assemblies' metadata which can cause
stack traces to display !Unknown. On Windows most debuggers like Windbg and VS can load
the module from file for this kind of dumps. On Linux lldb/SOS doesn't load the native
modules and really doesn't know anything about the managed assemblies.

Add metadata callback to datatarget and it's implementation in SOS.NETCore.

Add IsMetadataMemory() and the metadata region list. This is because lldb on core dumps
returns 0's on missing metadata memory reads instead of an error.
mikem8361 added a commit to mikem8361/diagnostics that referenced this issue May 1, 2019
Issue #dotnet#56

Both Windows and Linux minidumps don't save all the assemblies' metadata which can cause
stack traces to display !Unknown. On Windows most debuggers like Windbg and VS can load
the module from file for this kind of dumps. On Linux lldb/SOS doesn't load the native
modules and really doesn't know anything about the managed assemblies.

Add metadata callback to datatarget and it's implementation in SOS.NETCore.

Add IsMetadataMemory() and the metadata region list. This is because lldb on core dumps
returns 0's on missing metadata memory reads instead of an error.
mikem8361 added a commit that referenced this issue May 1, 2019
* Fix missing metadata in Linux core dumps.

Issue ##56

Both Windows and Linux minidumps don't save all the assemblies' metadata which can cause
stack traces to display !Unknown. On Windows most debuggers like Windbg and VS can load
the module from file for this kind of dumps. On Linux lldb/SOS doesn't load the native
modules and really doesn't know anything about the managed assemblies.

Add metadata callback to datatarget and it's implementation in SOS.NETCore.

Add IsMetadataMemory() and the metadata region list. This is because lldb on core dumps
returns 0's on missing metadata memory reads instead of an error.
@mikem8361
Copy link
Member Author

Fixed PR #229.

@ghost ghost locked as resolved and limited conversation to collaborators Jun 27, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants