diagnostics: trace.speedscope.json is empty (just 230B)

Description

$ dotnet-trace collect -p 6061 --format speedscope No profile or providers specified, defaulting to trace profile 'cpu-sampling'

Provider Name Keywords Level Enabled By Microsoft-DotNETCore-SampleProfiler 0x0000F00000000000 Informational(4) --profile Microsoft-Windows-DotNETRuntime 0x00000014C14FCCBD Informational(4) --profile

Process : /home/gysun/dotnet-sdk-3.1.401-linux-x64/dotnet Output File : /home/gysun/gysun-perf/trace.nettrace

[00:00:00:13] Recording trace 479.778 (KB) Press <Enter> or <Ctrl+C> to exit...

Trace completed. Writing: /home/gysun/gysun-perf/trace.speedscope.json Conversion complete

$ ls -lh trace.nettrace -rw-rw-r-- 1 gysun gysun 469K 9月 17 15:50 trace.nettrace

$ ls -lh trace.speedscope.json -rw-rw-r-- 1 gysun gysun 230 9月 17 15:50 trace.speedscope.json

Configuration

$ dotnet-trace --version 3.1.141901+3f460984c62efa118b6bd87fa4c5f07b11074b34

$ uname -a Linux fool-OptiPlex-7060 4.15.0-115-generic #116-Ubuntu SMP Wed Aug 26 14:04:49 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 1
Comments: 15 (11 by maintainers)

Commits related to this issue

Update TraceEvent fixes #1572 — committed to dotnet/diagnostics by deleted user 3 years ago
Update TraceEvent (#1878) fixes #1572 — committed to dotnet/diagnostics by deleted user 3 years ago

Most upvoted comments

Figured out why I couldn’t reproduce the original issue: I was running on Windows. There is an omission in the runtime that is causing all stacks on Windows to be marked as external code. When I collect the same trace for the same program on my Mac, I get the correct output which is a reproduction of the original issue.

My PR in TraceEvent should fix the conversion code in this case, but ~I’ll need to open a coreclr issue to address the underlying problem~ the underlying issue will be tracked here: dotnet/runtime#45179.

josalem on Nov 25, 2020

Have we asked @brianrob to do one? It sounds like we could use it : )

noahfalk on Jan 4, 2021

@josalem have we taken a traceevent update yet?

No, TraceEvent hasn’t done a release since that fix went in as far as I’m aware.

josalem on Dec 18, 2020

@josalem,

I have encountered the same problem, even after updating to version 5.0.152202+4d281c71a14e6226ab0bf0c98687db4a5c4217e3 from the (https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet5/nuget/v3/index.json) package source (was initially on v.3.1.141901, which had identical behaviour).

When capturing a trace on Windows 10, using:

dotnet-trace collect --format Speedscope -n NDI.TestApp --providers System.Runtime:0:1:EventCounterIntervalSec=1,DevDecoder.NDI:0:1:EventCounterIntervalSec=1

Where, DevDecoder.NDI is a set of custom events, I get a valid trace.nettrace file, but the trace.speedscope.json file is effectively empty.

I get the same problem with --format Chromium (also produces an ‘empty’ trace.chromium.json). I’ve included all 3 files in the attached zip (though the Chromium format was captured with an earlier run, it demonstrates the same ‘empty’ issue). Traces.zip

thargy on Oct 29, 2020