DevTools janky, OOM crashy with overly verbose callstacks |
|||
Issue descriptionChrome Version: 69.0.3497.57 (Official Build) beta (64-bit) OS: MacOS 10.13.5 What steps will reproduce the problem? (1) Use a data: URL to serve a script. (2) Make some recursive calls to make a nice fat stack. (3) Make a network request. (4) Loop a few times. What is the expected result? DevTools is responsive. What happens instead? Because DevTools puts the callstack in the message, the script URLs can be large and are duplicated once per frame, and the message is evaled by the DevTools backend, DevTools ends up consuming a ton of CPU compiling the dispatchMessage script and a ton of memory, presumably with the unique URL strings. One example use case where having DevTools open ties up a core and makes Chrome unusable: A video player component makes repeated network requests to buffer data, each of those Network.requestWillBeSent messages ends up being megabytes of data (mostly repeated data: URLs for the script) and chaos ensues. Yeah, shame on us for using data: URLs; on the other hand DevTools might scale better if messages sent a separate list of strings which V8 doesn't have to parse, and which would let the callstack refer to instead of repeating URLs. In our case there's probably about ~300K of data: URLs but it blows out to 15MB with the repetition in the callstack. Super bonus points if DevTools could be stateful and only transmit URLs once. Please use labels and text to provide additional information. Re: versions; this isn't a new issue.
,
Aug 25
,
Oct 8
Thanks for the report. To confirm, is it only the initiators from requestWillBeSent that is bloated?
It sounds like the site/component generates a ton of requestWillBeSent's events:
{
initiator: {
url, // this is a large data URL (1)
stack: {
callFrames: [{
scriptId,
url, // this is a large data URL (2)
}, ... (3)]
},
}
}
We could consider:
- new `Runtime.setStackTraceLimit()` with low default, similar to V8's `Error.stackTraceLimit`, and only use Infinity when needed (hover, HAR export)
- new `Runtime.scriptIdToUrl()` and carefully turn `url` into `displayURL`.
Trimming URLs affects DevTools/Lighthouse, which use initiator urls for comparison, linking, and exporting.
dgozman@, maybe you have better ideas?
,
Oct 8
Adding the following to the end of the data-url script will make us (and Error.stack) report just a short url. //# sourceUrl=myplayer.js I think we can just omit very large urls (like for anonymous scripts) in all messages except for ScriptParsed, as a product excellence fix.
,
Nov 15
Sorry for the slow reply; I have been on leave. Re: Comment 3, we detected this in our video player stack, it makes repeated network requests, fast enough to outpace DevTools' copy/parse & exec/collect. Per the original post, the data URL (1) is about 300 K and the (1) + (3) * (2) is ~15 MB per request. Re: Comment 4, thanks for the tip! |
|||
►
Sign in to add a comment |
|||
Comment 1 by dominicc@chromium.org
, Aug 24