Speed: memory leak on page in Chrome, not in Edge |
|||||
Issue descriptionWhen browsing to this (somewhat unsafe for work) page memory grows unbounded. This page has crashed due to OOM twice when I've left it open for a long time. http://www.thestranger.com/savage-love/2017/06/14/25209211/savage-love A canary devtools heap snapshot is available (Google employees only) here: https://drive.google.com/a/google.com/file/d/0B0_BQhEiKmSYdXh2ekdWbkx6am8/view?usp=sharing A canary chrome://tracing memory-infra traces is attached that covers the time period when the process starts. If possible I will attach one from later one when memory has grown. Note that the devtools heap snapshot was from a different run from the chrome://tracing trace, which is probably best given how much memory devtools can use.
,
Jun 19 2017
The numbers look pretty reasonable to me (see attachment). Did the renderer crashed (OOM) in that trace? How long did you ran the webpage before getting a memory snapshot?
,
Jun 19 2017
I looked to every objects allocated more than 10k times. Two processes contains some potential leaks (see attachement). The CSS potential leak is tracked here: https://bugs.chromium.org/p/chromium/issues/detail?id=733714 The sync potential leak is trackec here: https://bugs.chromium.org/p/chromium/issues/detail?id=732969
,
Jun 19 2017
Unfortunately my traces were both shortly after refreshing the page. I'm still figuring out the best data to get. It sounds like one of the best things to do is to get a devtools heap snapshot when the page is in its bloated state, whereas I was initially trying to use chrome://tracing with memory-infra.
,
Jun 20 2017
,
Aug 2 2017
,
Aug 3
Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by brucedaw...@chromium.org
, Jun 16 2017