New issue
Advanced search Search tips

Issue 599176 link

Starred by 2 users

Issue metadata

Status: Duplicate
Merged: issue 601459
Owner:
Closed: Apr 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Mac
Pri: 3
Type: Bug



Sign in to add a comment

Cannot import traces in traceviewer if category "cc.debug.scheduler.frames" is turned on

Project Member Reported by dproy@chromium.org, Mar 30 2016

Issue description

Version: 49.0.2623.108, 51.0.2694.1
OS: OSX 10.11, Goobuntu, probably on windows as well.

What steps will reproduce the problem?
Go to chrome://tracing and record a trace with the category "cc.debug.scheduler.frames" turned on. Spend 10 second browsing. Open a new webpage like github.com.

What is the expected output?
Successful import of the recorded trace.

What do you see instead?
ERROR!
Error: Could not find an importer for the provided eventData.
    at Object.createImports (chrome://tracing/tracing.js:436:64)
    at Object.Task.run (chrome://tracing/tracing.js:732:13)
    at runAnother (chrome://tracing/tracing.js:744:136)
    at runTask (chrome://tracing/tracing.js:707:57)
    at processIdleWork (chrome://tracing/tracing.js:713:116)

Notes
It seems like traces include characters that the JSON parser cannot parse. From preliminary investigation, the culprit seems to be the two location_string_.c_str() arguments. If I replace those arguments with "foo", the trace is imported fine. An unimportable trace file is attached.
 
trace_scheduler.json
607 KB View Download
Labels: Hotlist-GoodFirstBug
I can confirm that this is also an issue on Windows 10 Pro N Build 10240 using Chrome Canary 51.0.2697.0 (64-bit).
Your attached file contains binary data for the |name| property (for example on line 360). Normally this should be filled with the location of the calling code [1]. This is set when compiling via the |__LINE__| and |__FILE__| macros [2]. I've tried to reproduce the bug under Debian 8.3.0 (in a VM) with Chromium 47.0.2526.80 but failed to do so. However, with Chrome 49.0.2623.110 I get the same behavior as you.

Under Windows the problem seems to be different than reported by you - although the outcome is the same - the file cannot be parsed. Here, the |name| property contains the correct path but it is not escaped. This also leads to trace files which cannot be parsed. I will prepare a CL for this case.

[1] https://code.google.com/p/chromium/codesearch#chromium/src/cc/scheduler/begin_frame_tracker.cc&l=11,28,58
[2] https://code.google.com/p/chromium/codesearch#chromium/src/base/location.h&l=104,105
Filed  Issue 601459 , that code is passing const char* which do NOT have indeterminate lifetime to tracing.
Project Member

Comment 6 by bugdroid1@chromium.org, Apr 7 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c3074fbaf4ed55a4ebae511cb2bc943d0af532f9

commit c3074fbaf4ed55a4ebae511cb2bc943d0af532f9
Author: m.pistrich <m.pistrich@gmail.com>
Date: Thu Apr 07 21:06:47 2016

Escape name and category of trace events.

Some calls to trace an event pass a source location as name
(e.g. in BeginFrameTracker::Start). On Windows, these location paths are
separated by backslashes which were not escaped when saving as JSON.
This lead to unparsable trace files created by chrome://tracing.

R=primiano@chromium.org
BUG= 599176 
TEST=TraceEventTestFixture.NameAndCategoryEscapedIfNeeded

Review URL: https://codereview.chromium.org/1870563002

Cr-Commit-Position: refs/heads/master@{#385848}

[modify] https://crrev.com/c3074fbaf4ed55a4ebae511cb2bc943d0af532f9/base/trace_event/trace_event_impl.cc
[modify] https://crrev.com/c3074fbaf4ed55a4ebae511cb2bc943d0af532f9/base/trace_event/trace_event_unittest.cc

Mergedinto: 601459
Status: Duplicate (was: Untriaged)
Ok at this point I believe that the only action left is fixing  Issue 601459 
Duping against that.
If somebody wants to fix it, that should really a 1 minute thing.
Components: Speed>Tracing
Labels: -Performance-Tracing

Sign in to add a comment