Issue metadata
Sign in to add a comment
|
chrome://tracing fails to display the trace
Reported by
pkandrus...@googlemail.com,
Jan 6 2017
|
||||||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
Steps to reproduce the problem:
1. Open chrome://tracing
2. Open test.txt
What is the expected behavior?
A trace is displayed.
What went wrong?
Nothing is displayed with the following error in the console:
Uncaught (in promise) Error: The trace is too long or the CPU usage counter interval is too small, leading to too many CPU usage intervals.
at HTMLDivElement.computeCpuUsage_ (tracing.js:4194)
at HTMLDivElement.initialize (tracing.js:4193)
at HTMLDivElement.appendCpuUsageTrack_ (tracing.js:4386)
at HTMLDivElement.updateContentsForLowerMode_ (tracing.js:4376)
at HTMLDivElement.updateContents_ (tracing.js:4373)
at HTMLDivElement.set model [as model] (tracing.js:4370)
at HTMLElement.set model [as model] (tracing.js:4421)
at HTMLElement.set model [as model] (tracing.js:4591)
at HTMLElement.<anonymous> (tracing.js:4607)
Did this work before? Yes exact number unknown, functional around Aug 2016
Chrome version: 55.0.2883.87 Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 24.0 r0
After removing the least significant digit from each timestamp the file loads. Modified file attached as test1.txt
,
Jan 10 2017
,
Jan 17 2017
Thank you for providing more feedback. Adding requester "ranjitkan@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 19 2017
Thanks a lot for the feedback provided, able to reproduce the issue and below are the bisect details for the same: Bisect info: ============ 53.0.2780.0 - Good Build 53.0.2785.0 - Bad build: Change log: https://chromium.googlesource.com/chromium/src/+log/6311f0fdc42799da33b9e28e6b784a1eda788aa0..298aa38b91c86e1540aeb2a1c119c9040715037c Suspecting the below change could be a possible culprit: https://chromium.googlesource.com/external/github.com/catapult-project/catapult.git/+/403dec7cf147396400a292e2904e5c325f06c1ee @alexandermont: Assigning to you, kindly have a look into it. Please help us to find an owner if not with respect to your change. Issue is not observed on MAC OS. Thanks.!
,
Jan 19 2017
I have seen this issue before. It has to do with how the CPU trace graph is creating. I'm currently in the middle of a major refactoring of how this graph is created, which should fix this problem. I will make sure to test on the file you gave before submitting my change.
,
Feb 10 2017
,
Feb 10 2017
,
Mar 24 2017
We're seeing this issue when trying to load small manually generated traces with large timestamps, and also when loading large ninja-tracing traces of builds. Reproduces on 55.0.2883.87 However, the issue seems fixed in the 459381 nightly snapshot. I have not looked into when exactly it got fixed, but would be nice to have it working in stable sooner rather than later. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by alph@chromium.org
, Jan 10 2017