profile
viewpoint

leculver/clrmd 0

Microsoft.Diagnostics.Runtime is a set of APIs for introspecting processes and dumps.

leculver/coreclr 0

This repo contains the .NET Core runtime, called CoreCLR, and the base library, called mscorlib. It includes the garbage collector, JIT compiler, base .NET data types and many low-level classes.

leculver/diagnostics 0

This repository contains the source code for various .NET Core runtime diagnostic tools and documents.

leculver/dotnet 0

This repo is the official home of .NET on GitHub. It's a great starting point to find many .NET OSS projects from Microsoft and the community, including many that are part of the .NET Foundation.

leculver/dotnet-reliability 0

.NET reliability and stress test tooling

leculver/mono 0

Mono open source ECMA CLI, C# and .NET implementation.

leculver/monodevelop 0

MonoDevelop is a cross platform .NET IDE

leculver/runtime 0

.NET is a cross-platform runtime for cloud, IoT, mobile and desktop apps.

leculver/symstore 0

Implements API for publishing and retrieval of symbols and other debug artifacts from symbol store.

leculver/WinDbgCs 0

WinDbg extension for executing C# scripts

issue openedmicrosoft/perfview

Stack viewer: Support "ALT+V" when selecting time range in "When" column

Currently when selecting a time range in the "When" column and pressing "ALT + V" it will display:

Could not parse cells as time range

It would be helpful if this opened the events with the selected range.

created time in a day

pull request commentmicrosoft/perfview

Handle ThreadUninitialized case in SampleProfilerThreadTimeComputer

@josalem thank you for fixing the issue and adding more tests!

josalem

comment created time in 2 days

push eventmicrosoft/perfview

John Salem

commit sha dc59278a51a6a18385faf5a918507fca47f9b65a

Also log CPU samples if thread is "uninitialized"

view details

John Salem

commit sha c257c1931d6518dc18ad1eb89c2d08432a3010a2

Handle unitialized case for onCPU and offCPU

view details

John Salem

commit sha 02ca4d8cca81abeb03fff402be36c1b901610791

Add test cases

view details

Brian Robbins

commit sha 84c9c6e21469efed46f2170e3f047c39d2d1f02e

Merge pull request #1329 from josalem/dev/josalem/thread-state-fix Handle ThreadUninitialized case in SampleProfilerThreadTimeComputer

view details

push time in 3 days

PR merged microsoft/perfview

Reviewers
Handle ThreadUninitialized case in SampleProfilerThreadTimeComputer

fixes dotnet/diagnostics#1572

See dotnet/diagnostics#1572 for details on the issue. Summary: There are some nettrace files that don't produce any stacks in speedscope or chromium trace conversions.

I'm pretty sure I've identified the issue. I'm not 100% sure if this the "correct" solution, but I know it fixes the issue. The logic that I believe is at fault is here:

https://github.com/microsoft/perfview/blob/e7a025a9ac9bec1348beeb118b8eb986fcd42703/src/TraceEvent/Computers/SampleProfilerThreadTimeComputer.cs#L475-L555

This section in particular is the one to blame:

            public void LogThreadStack(double timeRelativeMSec, StackSourceCallStackIndex stackIndex, TraceThread thread, SampleProfilerThreadTimeComputer computer, bool onCPU)
            {
                if (onCPU)
                {
                    if (ThreadRunning) // continue running 
                    {
                        AddCPUSample(timeRelativeMSec, thread, computer);
                    }
                    else if (ThreadBlocked) // unblocked
                    {
                        AddBlockTimeSample(timeRelativeMSec, thread, computer);
                        LastBlockStackRelativeMSec = -timeRelativeMSec;
                    }

                    LastCPUStackRelativeMSec = timeRelativeMSec;
                    LastCPUCallStack = stackIndex;
                }
                else
                {
                    if (ThreadBlocked) // continue blocking
                    {
                        AddBlockTimeSample(timeRelativeMSec, thread, computer);
                    }
                    else if (ThreadRunning) // blocked
                    {
                        AddCPUSample(timeRelativeMSec, thread, computer);
                    }

                    LastBlockStackRelativeMSec = timeRelativeMSec;
                    LastBlockCallStack = stackIndex;
                }
            }

If all the samples in a trace are onCPU, the thread is never put into the blocked state, so ThreadRunning never returns true:

public bool ThreadRunning { get { return LastBlockStackRelativeMSec < 0 && !ThreadDead; } }

If ThreadRunning is never true, no samples are put into the stack source because it never calls AddCPUSample or AddBlockTimeSample. This results in no stacks in the output.

I fixed this by simply changing the first check to be if (ThreadRunning || ThreadUninitialized) so that the thread state starts correctly if all the samples are managed code.

CC @sywhang @adamsitnik

+11 -2

5 comments

4 changed files

josalem

pr closed time in 3 days

pull request commentmicrosoft/perfview

Handle ThreadUninitialized case in SampleProfilerThreadTimeComputer

Added two test cases using traces I generated locally that fail under the old logic.

josalem

comment created time in 3 days

pull request commentmicrosoft/perfview

Also log CPU samples if thread is "uninitialized"

All of the samples in a trace collected on Windows will be marked as external, while they will be correctly split between managed and external on non-Windows platforms. See dotnet/runtime#45179 for more details on the underlying runtime issue.

josalem

comment created time in 4 days

PR opened microsoft/perfview

Add tests for handling TraceEvent symbol reader

This adds some basic tests for the Microsoft.Diagnostics.Symbols classes. Namely it tests:

  • Source resolution works correctly, including SourceLink
  • Disposing a symbol module will drop file locks
+227 -0

0 comment

2 changed files

pr created time in 4 days

pull request commentmicrosoft/perfview

Also log CPU samples if thread is "uninitialized"

Can you tell from an individual event that the thread should be marked as OnCPU?

Yes, you should be able to. Every sample event has a payload that indicates the GC Mode when the sample was taken. This is used to interpret whether a stack is "managed" (coop) or "external" (preemptive). onCPU's value is determined by whether the sample event is marked as "managed" (true) or "external" (false).

The main issue with the current logic is that ThreadRunning and ThreadBlocked are both determined using the value of LastBlockStackRelativeMSec. Those two values are what cause AddBlockTimeSample and AddCPUSample to be called. If all samples are marked as onCPU (managed samples), then LastBlockStackRelativeMSec will always be 0 (uninitialized) causing ThreadRunning and ThreadBlocked to be false.

https://github.com/microsoft/perfview/blob/e75e3856d53c123c7f7ba202579d44ba4d91a7b8/src/TraceEvent/Computers/SampleProfilerThreadTimeComputer.cs#L544-L547

This results in all samples before an onCPU == false sample being thrown out since neither Add*Sample method will be called.

A more correct solution might be something like this:

            public void LogThreadStack(double timeRelativeMSec, StackSourceCallStackIndex stackIndex, TraceThread thread, SampleProfilerThreadTimeComputer computer, bool onCPU)
            {
                if (onCPU)
                {
					if (ThreadUninitialized) // first sample is onCPU
					{
						AddCPUSample(timeRelativeMSec, thread, computer);
						LastBlockStackRelativeMSec = -1; // set ThreadRunning to true
					}
                    if (ThreadRunning) // continue running 
                    {
                        AddCPUSample(timeRelativeMSec, thread, computer);
                    }
                    else if (ThreadBlocked) // unblocked
                    {
                        AddBlockTimeSample(timeRelativeMSec, thread, computer);
                        LastBlockStackRelativeMSec = -timeRelativeMSec;
                    }

                    LastCPUStackRelativeMSec = timeRelativeMSec;
                    LastCPUCallStack = stackIndex;
                }
                else
                {
                    if (ThreadBlocked || Uninitialized) // continue blocking
                    {
                        AddBlockTimeSample(timeRelativeMSec, thread, computer);
                    }
                    else if (ThreadRunning) // blocked
                    {
                        AddCPUSample(timeRelativeMSec, thread, computer);
                    }

                    LastBlockStackRelativeMSec = timeRelativeMSec;
                    LastBlockCallStack = stackIndex;
                }
            }

to make sure the state machine covers the uninitialized state. We simply assume that the starting state of the thread is "running" if the first event is onCPU == true and "blocked" if its onCPU == false.

josalem

comment created time in 4 days

push eventmicrosoft/perfview

Brian Robbins

commit sha 69dd248217ab25bdf290ac92cb4db5a94e3585f4

Increment PerfView and TraceEvent versions.

view details

Brian Robbins

commit sha 7e9854f2a5b28211a2ca3f20b12394cd92af4d04

Merge pull request #1331 from brianrob/increment-version Increment PerfView and TraceEvent versions

view details

push time in 4 days

pull request commentmicrosoft/perfview

Also log CPU samples if thread is "uninitialized"

@josalem, I suspect you're right that this might not be the right solution, though it does work. Can you tell from an individual event that the thread should be marked as OnCPU? Usually, the right answer is when you see one of these, to update the data structure to make sure that the thread is considered OnCPU and running. Is that do-able, or are we operating with not enough information here to do this?

josalem

comment created time in 4 days

push eventmicrosoft/perfview

Andrew Au

commit sha 877c4da519231f9e696176e83aa54cef918bebb4

Decoding traces produced by generational aware analysis.

view details

Brian Robbins

commit sha 3a9b3aa51de8ca80615c72c9fd50bbd85977dd7c

Merge pull request #1250 from cshung/public/dev/andrewau/decode-genaware-events Decoding traces produced by generational aware analysis.

view details

push time in 4 days

PR merged microsoft/perfview

Decoding traces produced by generational aware analysis.

Here are the changes required to decode the traces produced by generational aware analysis I introduced in https://github.com/dotnet/runtime/pull/40332

Notice the latest change requires https://github.com/dotnet/runtime/pull/41052

+185 -3

3 comments

4 changed files

cshung

pr closed time in 4 days

push eventmicrosoft/perfview

Tom Pažourek

commit sha c80fb0d6d313293d518aff3ce7ece31ebdbb6f44

Added TraceEvent.props to nuspec also as buildTransitive, fixes #1301.

view details

Brian Robbins

commit sha 99fd3b849a4b7ed3e4eb330739944d089d6f1c2f

Merge pull request #1312 from tompazourek/issue-1301-buildtransitive Added TraceEvent.props to nuspec also as buildTransitive

view details

push time in 4 days

PR merged microsoft/perfview

Added TraceEvent.props to nuspec also as buildTransitive

Fixes #1301, see that for more info.

+1 -0

5 comments

1 changed file

tompazourek

pr closed time in 4 days

issue closedmicrosoft/perfview

The "build" assets in the "Microsoft.Diagnostics.Tracing.TraceEvent" package should also be "buildTransitive"

Problem

The Microsoft.Diagnostics.Tracing.TraceEvent.props file that's stored inside the build folder of the Microsoft.Diagnostics.Tracing.TraceEvent package is responsible for copying the native DLLs to the output directory. (Looking at the current version 2.0.61)

However, due to the nature of how build assets work in NuGet, this will only be applied on the project that directly references this package. If there's another dependency step between, the native DLLs will not end up in the other projects. More info here.

Example

For example, ProjectA references the Microsoft.Diagnostics.Tracing.TraceEvent package, and WebApplicationB references ProjectA. Then the native DLLs won't end up in the final output of WebApplicationB, which is where they are needed, because ProjectA is just a class library, not an executable.

Solution?

This can be solved by having the Microsoft.Diagnostics.Tracing.TraceEvent.props file twice in the NuGet package -- once in the build folder, and once in the buildTransitive folder.

closed time in 4 days

tompazourek

push eventmicrosoft/perfview

Sam Harwell

commit sha a28226c72f0e118aab0c4fda6d23a22936318fdf

Set indentation for project files in .editorconfig

view details

Brian Robbins

commit sha b1fefe06b32c6d01327f887acb35f79b4c0ce13f

Merge pull request #1323 from sharwell/set-indentation Set indentation for project files in .editorconfig

view details

push time in 4 days

push eventmicrosoft/perfview

Gregg Miskelly

commit sha 10c3183b2ac9be36e75357587c8dda60b3091291

TraceEvent symbol handler source file improvements This PR exposes some additional information from the SourceFile classes. This also fixes some issues with source file handling New exposed APIs: - In addition to the URL property, there is now a new 'GetSourceLinkInfo' method that exposes the URL and the relative file path - The checksum value/algorithm is exposed Fixes: - The old code didn't calculate checksum's in Windows PDBs for managed code correctly - it only expected the 'C++ way' of encoding checksums, but that isn't how diasymreader.dll does it. - The old code serched for sourcelink info in a native PDB via a very hacky method. This switches to doing things the right way. Along with this, I had to tweak the internal interface used to return source link data into something that could return multiple strings instead of just a single one.

view details

Gregg Miskelly

commit sha f5b4b365489c1ea7a3c86fc6c09c10689c153c1e

Code review fixes

view details

Gregg Miskelly

commit sha ee6106de4589fb8c44a8acacf200144201876a9a

Implement IDisposable on NativeSymbolModule This checkin changes NativeSymbolModule to implement IDisposable using IDiaSession3.dispose. This is important for any scenario where a caller wants to guranteee PDBs are unloaded since finial release of the underlying COM objects will happen at a non-deterministic point.

view details

Brian Robbins

commit sha bd60a3a527e75e7448ccd005678c96fafd38967f

Merge pull request #1330 from gregg-miskelly/dev/greggm/SymbolSourceImprovements TraceEvent symbol handler source file improvements

view details

push time in 4 days

PR merged microsoft/perfview

TraceEvent symbol handler source file improvements

This PR exposes some additional information from the SourceFile classes. This also fixes some issues with source file handling

New exposed APIs:

  • In addition to the URL property, there is now a new 'GetSourceLinkInfo' method that exposes the URL and the relative file path
  • The checksum value/algorithm is exposed
  • NativeSymbolModule now implements IDisposable using IDiaSession3.dispose

Additional fixes:

  • The old code didn't calculate checksum's in Windows PDBs for managed code correctly - it only expected the 'C++ way' of encoding checksums, but that isn't how diasymreader.dll does it.
  • The old code serched for sourcelink info in a native PDB via a very hacky method. This switches to doing things the right way. Along with this, I had to tweak the internal interface used to return source link data into something that could return multiple strings instead of just a single one.

Testing:

Verified the source file info we get from:

  1. A default C# .NET Framework console app (Windows PDB case)
  2. A C# .NET Framework project with Source Link (Windows PDB case)
  3. Newtonsoft Json's PDB (Portable PDB with Source Link info)
  4. C++ project with Source Link
  5. C++ project with srcsrv
+412 -88

0 comment

3 changed files

gregg-miskelly

pr closed time in 4 days

MemberEvent
MemberEvent
MemberEvent

pull request commentmicrosoft/perfview

Also log CPU samples if thread is "uninitialized"

I think there may be more to the problem than this PR is addressing. This PR addresses the fact that a trace that contains samples only marked as managed will not be computed correctly. There may be a lower level issue surrounding whether a stack is marked as managed or not. Refer to the issue mentioned in the PR text for more details.

josalem

comment created time in 4 days

Pull request review commentmicrosoft/perfview

TraceEvent symbol handler source file improvements

 internal unsafe MicrosoftPdbSourceFile(NativeSymbolModule module, IDiaSourceFile             {                 BuildTimeFilePath = sourceFile.fileName; -                // 0 No checksum present.+                if (sourceFile.checksumType == 0)+                {+                    // If the checksum type is zero, this means either this is a non-C++ PDB, or there is no checksum info+                    TryInitializeManagedChecskum(module);

Nit: Spelling --> TryInitializeManagedChecksum

gregg-miskelly

comment created time in 5 days

Pull request review commentmicrosoft/perfview

TraceEvent symbol handler source file improvements

 public virtual string GetSourceFile(bool requireChecksumMatch = false)         /// </summary>         public bool HasChecksum { get { return _hashAlgorithm != null; } } +        /// <summary>+        /// Gets the name of the algorithm used to compute the source file hash. Values should be from System.Security.Cryptography.HashAlgorithmName.+        /// This is null if there is no checksum.+        /// </summary>+        public string ChecksumAlgorithm+        {+            get+            {+                if (_hashAlgorithm == null)+                {+                    return null;+                }+                else if (_hashAlgorithm is SHA256)+                {+                    return "SHA256";+                }+                else if (_hashAlgorithm is SHA1)+                {+                    return "SHA1";+                }+                else if (_hashAlgorithm is MD5)+                {+                    return "MD5";+                }+                else+                {+                    Debug.Fail("Missing case in get_ChecskumAlgorithm");

Nit: Spelling --> get_ChecksumAlgorithm.

gregg-miskelly

comment created time in 5 days

issue closedmicrosoft/perfview

Export to speedscope sometimes has asymmetrical open/close frame event sequencing

Hi! I received a bug report to speedscope (https://github.com/jlfwong/speedscope/issues/272) which I'm fairly sure is caused by the event sequencing of the speedscope export of nettrace being incorrect. There's more in-depth discussion of the problem and relevant files in that issue.

If someone does plan on patching this issue, it would also be helpful to update this line:

https://github.com/microsoft/perfview/blob/9ca3b2e803d862935fd29789d550fe97a3bc9b4e/src/TraceEvent/Stacks/SpeedScopeStackSourceWriter.cs#L55

The intent of that field in the file format is to indicate what program exported the file so I can figure out if it's a bug in speedscope's export format or not. In this particular case, it was not, but if it weren't for @swift-kim being very thorough in their bug report, I might've gone down a rabbit hole trying to figure out where the bug was.

I'd prefer if that line was instead:

 writer.Write("\"exporter\": \"microsoft/perfview\", "); 

possibly with a version number.

closed time in 5 days

jlfwong

PR opened microsoft/perfview

TraceEvent symbol handler source file improvements

This PR exposes some additional information from the SourceFile classes. This also fixes some issues with source file handling

New exposed APIs:

  • In addition to the URL property, there is now a new 'GetSourceLinkInfo' method that exposes the URL and the relative file path
  • The checksum value/algorithm is exposed

Fixes:

  • The old code didn't calculate checksum's in Windows PDBs for managed code correctly - it only expected the 'C++ way' of encoding checksums, but that isn't how diasymreader.dll does it.
  • The old code serched for sourcelink info in a native PDB via a very hacky method. This switches to doing things the right way. Along with this, I had to tweak the internal interface used to return source link data into something that could return multiple strings instead of just a single one.
+250 -84

0 comment

3 changed files

pr created time in 5 days

issue commentmicrosoft/perfview

Export to speedscope sometimes has asymmetrical open/close frame event sequencing

#1212 contained a proper fix, the issue can be closed now @brianrob

jlfwong

comment created time in 5 days

more