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

Mini-dump thread stack frames are missing #980

Open
iliamosko opened this issue Mar 14, 2022 · 2 comments
Open

Mini-dump thread stack frames are missing #980

iliamosko opened this issue Mar 14, 2022 · 2 comments

Comments

@iliamosko
Copy link

After upgrading our dump parsing application to CLRMD v2.0, and attempting to parse a mini-dump, we are seeing missing stack frames for some threads. The mini-dump was taken from a process that is running on Ubuntu-20.04 and is also being parsed on the same system.

Here are some screenshots of a thread and its stack frame traced using Dotnet-dump analyze, a sample clrstack class file provided in the CLRMD repository and our custom tracing application running on CLRMD v1.1.

Any idea as to what is causing this issue?

Dotnet-dump analyze:
image

CLRMD v2.0 sample dump parser:
https://github.com/microsoft/clrmd/blob/124b189a2519c4f13610c6bf94e516243647af2e/src/Samples/ClrStack/ClrStack.cs
(*** The only modification done to this class was that I removed the parsing of DumpStackObjects so that there are only thread callstacks in the output.)
image

Application running CLRMD v1.1:
image

@leculver
Copy link
Contributor

This is typically due to not being able to properly find PE images for the files in question. We have a System.Diagnostics.Trace.WriteLine call in ClrMD (both versions I think) which prints out messages, for example: https://github.com/microsoft/clrmd/blob/master/src/Microsoft.Diagnostics.Runtime/src/Implementation/SymbolServerLocator.cs#L239

You can see these in Visual Studio's debugger events, or you can connect a standard listener to Diagnostics.Trace to write out to console. Can you collect that data and post it here? That should explain what's going on.

@iliamosko
Copy link
Author

I've ran the parser with a listener connected, but I received no Trace messages from the SymbolServerLocator. I've also tried to load the binaries before enumerating through the threads.

        foreach (var module in dataTarget.EnumerateModules())
        {
            Console.WriteLine($"Finding binary: {module.FileName}");
            var binaryLocation = dataTarget.BinaryLocator.FindBinaryAsync(module.FileName, module.IndexTimeStamp, module.IndexFileSize, true);
            Console.WriteLine($"FindBinary output: {binaryLocation.Result}");
        }

Each module that was ran through the BinaryLocator returned the module location so I dont think that there are files missing(?).

I've also noticed that the ability to set a symbol path to the SymbolLocator has been removed, instead it is checking for environment variables set beforehand. This could be the cause of the problem if there are any binaries that are not found and are needed to be downloaded from the server, but this doesn't hold since CLRMD 2.0 parses our full-dumps without a problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants