Memory leak with very large source maps (100mb+)
Reported by
qfo...@gmail.com,
Feb 6 2018
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36 Steps to reproduce the problem: 1. Load a page with code that uses a very large source map (100mb+) 2. Refresh a few times 3. Observe that every refresh takes longer and longer What is the expected behavior? Devtools should tear down the source maps on refresh What went wrong? It seems to retain the source maps which bogs down the browser. Did this work before? N/A Chrome version: Channel: n/a OS Version: Flash Version: I realize 100mb source maps aren't your average use case. The case illustrates that there is a memory leak somewhere regarding source maps and that's just bad overall. (FD: I'm a dev at fb. We think it's a generic mem leak. If it that's not the case and something specific is hit let me know and I'll try to get a more proper test case. Thanks!)
,
Feb 6 2018
,
Feb 14 2018
I've done some debugging for you and I think OP is correct--this appears to be a leak and a lot of time is in MinorGC. Almost all of the bytes are in SDK.SourceMapEntry objects via SDK.TextSourceMap. It looks like there are a couple of kinds of retainers: Workspace.UISourceCode -> Sources.JavaScriptSourceFrame -> ... UI.PopoverHelpers ... DOM (presumably this one: <https://cs.chromium.org/chromium/src/third_party/WebKit/Source/devtools/front_end/sources/JavaScriptSourceFrame.js?l=47>) Workspace.UISourceCode -> Persistence.Persistence _subscribedBindingEventListeners. So just at a guess: 1. JavaScriptSourceFrame.dispose should unwire its UI.PopoverHelper from the scroll event (and maybe others.) 2. UISourceCodeFrame should unregister this binding event listener, perhaps by adding a dispose() method. <https://cs.chromium.org/chromium/src/third_party/WebKit/Source/devtools/front_end/sources/UISourceCodeFrame.js?q=UISourceCodeFrame&sq=package:chromium&l=62>
,
Mar 28 2018
r540973 may have helped this somewhat by adding a dispose to the PopoverHelper.
,
Apr 9 2018
This is still leaking, although not as much. I suspect this is leaking closures. In Inspector I see a lot of strings like: DevToolsAPI.streamWrite(6, "CuUDF6yhD,C0BFC0rkB,C+cMG+gW,CmDCC2e,C0WCD61wC,C6SKFmziB,CqLDG+u8C,CoXHFmqiC,C8aOG+s2... DevTools say these are only 40 bytes, which wouldn't include the external string, so the actual impact of these might be greater than it appears. |
|||
►
Sign in to add a comment |
|||
Comment 1 by krajshree@chromium.org
, Feb 6 2018