tracing fails with gzip error |
||
Issue descriptionWhat steps will reproduce the problem? (1) Install ghostery extension (2) Go to politico.com (3) Start a ract with all left column record categories selected and the renderer.scheduler right column category (4) cmd+click 3 articles to open as background tabs (5) Wait for the trace to hit 100% and hit stop. I get this error: RangeError: Inflated gzip data too long to fit into a string (407645029). at Function.GzipImporter.inflateGzipData_ (chrome://tracing/tracing.js:5439:201) at GzipImporter.extractSubtraces (chrome://tracing/tracing.js:5443:276) at Import.createImports (chrome://tracing/tracing.js:1378:112) at Task.run (chrome://tracing/tracing.js:2394:13) at runAnother (chrome://tracing/tracing.js:2405:160) at runTask (chrome://tracing/tracing.js:2369:57) at processIdleWork (chrome://tracing/tracing.js:2375:116) at window.requestIdleCallback.timeout (chrome://tracing/tracing.js:2363:81)
,
Mar 13 2017
I think tracing v2 (i.e., more efficient wire encoding) is the practical fix for this problem. As a workaround, please try commenting out this line: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/scheduler/renderer/renderer_scheduler_impl.cc?rcl=3fa8e5f655b856cc26a907d2354502eaefb8232c&l=1121 Just checking: you didn't also have the renderer.scheduler.debug category enabled, did you? That one emits a *huge* amount of data that isn't usually necessary.
,
Mar 15 2017
|
||
►
Sign in to add a comment |
||
Comment 1 by ojan@chromium.org
, Mar 13 2017