Issue metadata
Sign in to add a comment
|
Exception importing a memory trace that's only 5% full. |
||||||||||||||||||||||
Issue descriptiongroby: """ While importing: RangeError: Inflated gzip data too long to fit into a string (462377610). at Function.GzipImporter.inflateGzipData_ (chrome://tracing/tracing.js:4850:201) at GzipImporter.extractSubtraces (chrome://tracing/tracing.js:4854:276) at Import.createImports (chrome://tracing/tracing.js:1342:112) at Task.run (chrome://tracing/tracing.js:2066:13) at runAnother (chrome://tracing/tracing.js:2077:160) at runTask (chrome://tracing/tracing.js:2041:57) at processIdleWork (chrome://tracing/tracing.js:2047:116) at window.requestIdleCallback.timeout (chrome://tracing/tracing.js:2035:81) """ erikchen: """ can you take a shorter trace? Don't need any of the usual tracing categories only need that one box selected """ groby: """ I did. And I only went to "buffer 5% full" Trying 2% now """ [that ended up working].
,
Nov 15 2016
Is the unzipped trace bigger than 128 MB? If so that's unfortunately a KI which should be fixed with bit.ly/TracingV2 > I did. And I only went to "buffer 5% full" Unfortunately that % is a lie. Reasons explained here https://docs.google.com/document/d/18GIMFc36PhRW4zVnVJ_fcw3ybN-xbVtj7vjuY6duez0/edit#heading=h.blw16d2b29ul
,
Nov 15 2016
There is also https://github.com/catapult-project/catapult/issues/2826 about making trace parsing not blocked by the string size limit in js.
,
Nov 15 2016
,
Nov 16 2016
[mac triage] assigning to a tracing owner for further triage.
,
Nov 19 2016
KI partly being solved by https://github.com/catapult-project/catapult/issues/2826 fully by bit.ly/TracingV2 |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by nedngu...@google.com
, Nov 15 2016