New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 662285 link

Starred by 2 users

Issue metadata

Status: Duplicate
Merged: issue 679768
Owner:
Closed: Jan 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

Errors attempting to record and save Chrome trace

Reported by actinpe...@gmail.com, Nov 4 2016

Issue description

Chrome Version       :
Operating System and Version: 

Google Chrome	53.0.2785.154 (Official Build) (64-bit)
Revision	0
Platform	8530.96.0 (Official Build) stable-channel parrot
Blink	537.36 (@0)
JavaScript	V8 5.3.332.47
Flash	23.0.0.162-r1
User Agent	Mozilla/5.0 (X11; CrOS x86_64 8530.96.0) 


NOTICE: The report, even compressed, was too big.  Now, since this WAS for a memory / cpu-usage problem, but since there is no attached report, BUT since the tracer itself failed, please consider the following description as context and the Notes as the issues:



Description of performance problem:

https://video2.timewarnercable.com/livetv

Task manager shows page continues consuming more and more shared/private memory at about 20k/s, and page's cpu is over 95%, even though stopped at a breakpoint in devtools (over 2 hours now) -- though for Shockwave-plugin, memory stays basically constant and cpu is around 1%

As of submit-time, current page-mem is now over 750k. (peaked, over 800k)


Remember to attach your trace file to this bug!


Notes: 

0. Report, even compressed, was 2MB too big.  Since report is generated per given instructions, there should be a way to estimate size in advance, as it seems to depend in part on number of open tabs.


1. Tried to capture 2nd trace with State Sampling too, but upon import...

While importing:
RangeError: Inflated gzip data too long to fit into a string (275510253).
    at Function.GzipImporter.inflateGzipData_ (chrome://tracing/tracing.js:3832:204)
    at Object.extractSubtraces (chrome://tracing/tracing.js:3836:276)
    at Object.createImports (chrome://tracing/tracing.js:695:112)
    at Object.run (chrome://tracing/tracing.js:1199:13)
    at runAnother (chrome://tracing/tracing.js:1211:136)
    at runTask (chrome://tracing/tracing.js:1174:57)
    at processIdleWork (chrome://tracing/tracing.js:1180:116)
    at window.requestIdleCallback.timeout (chrome://tracing/tracing.js:1168:81)


2. Several attempts to capture 2nd trace with JUST State Sampling, gave error "Aw, Snap!" at some unobserved point.


3. Even after reopening tracer-tab several times, further attempts to record gave:

Error while recording
Error: Error occured at /json/categories
    at chrome://tracing/tracing.js:975:255


4. browser restart not attempted.


-end-

 
Components: Internals
Labels: OS-Chrome
Components: -Internals Internals>Tracing
Labels: -Performance Performance-Memory Performance-Tracing
Owner: sullivan@chromium.org
Summary: Errors attempting to record and save Chrome trace (was: Performance issue: meta-bugs -- Performance issue reporting)
Thanks for the report, and let me apologize for the trouble you encountered. I've split the issue with the video player off into issue 678112. Let's use this issue to dive into the tracing problems.

+sullivan, who would be best to take a look at these issues? 1 and 3 seem like specific bugs, whereas 0 and 2 and general "traces are too big". Not sure if there's an existing bug for that already.
Sorry, that's  issue 678122  that I split off.
Cc: aiolos@chromium.org nduca@chromium.org charliea@chromium.org benjhayden@chromium.org nednguyen@chromium.org
cc-ing some folks who've looked at trace size issues before--should this be merged into another issue?
The current plan to fix this is to use JSONStream:
https://github.com/catapult-project/catapult/issues/2826

Mergedinto: 679768
Status: Duplicate (was: Unconfirmed)
Given the impact of this bug, I went ahead and filed a Chromium-side bug for it.
Components: Speed>Tracing
Labels: -Performance-Tracing

Sign in to add a comment