Memory bloat in browser process - Ubuntu/Beta
Reported by
kanepy...@gmail.com,
Nov 1 2017
|
|||||||
Issue descriptionChrome Version: 63.0.3239.18 (beta) OS: Ubuntu 16.04.3 LTS URL (if applicable) where the memory bloat occurred: Browser process Can you reproduce this memory bloat? Yes, on a daily basis What steps will reproduce this memory bloat (or if it's not reproducible, what were you doing until then)? (1) Heavy usage of webapps including TweetDeck, multiple YouTube tabs, Slack, IRCCloud, Feedly, Discourse. The browser process grows over the minutes/hours until it fills up RAM, causing hitching when memory must be unswapped. No filtering of information from the attached memory logs was necessary (contains only Linux user name, one extension ID) Memory logs were taken 6 minutes apart. As of time of reporting, (15 minutes after first memlog) browser process has grown to 1GB reported in the Chrome task manager. This issue appeared to have been mitigated in the past by removing the "Profile 5" folder and re-downloading user data via Sync, but seems to have returned.
,
Nov 2 2017
,
Nov 2 2017
,
Nov 4 2017
It was particularly bad today when I watched a 30-person SpeedRunsLive race, which involves one Twitch.tv player embed per person. As always, the memory remained until I performed a full restart of Chrome.
,
Nov 5 2017
,
Nov 6 2017
Erik, can you help with triage? What debugging info should we collect? (Also, is there a doc on that we can link users to?)
,
Nov 6 2017
Thank you for reporting this! Unfortunately, the beta branch doesn't have all of the newest memlog code, and the traces you've uploaded don't contain full backtraces, nor MDP information. If you have the time, can you: 1) install chrome dev channel, 2) Make sure --memlog=minimal is enabled [it looks like you've figured that out]. Instructions are here: https://cs.chromium.org/chromium/src/chrome/profiling/README.md?type=cs&q=profiling.*md&sq=package:chromium&l=8 3) Wait for browser to bloat. 4) Take a memory-infra trace using chrome://tracing, as per instructions in (2).
,
Nov 6 2017
Oh blergh, please hold on. I just tried these steps on Linux, and we're still getting not-very-interesting back-traces. I bet there's something broken here.
,
Nov 7 2017
ajwong was going to look at fixing backtrace on Linux.
,
Nov 8 2017
I think it might have something to do with video decoding - the bloat isn't as big during stretches where I don't view any video content.
,
Nov 27 2017
Pinging back on this - do you have a bug filed for making the memory trace useful that this can be BlockedOn ? (#12 said "Blocker bug" which is not the right words I believe?)
,
Nov 28 2017
Thanks for checking back! This is fixed by commit 9f966099a3d6f91c80016226fe9d33981f291689 [516596], which will be present in the next Dev release for Linux [which will hopefully come out this week]. http://omahaproxy.appspot.com/ The current dev release is branched from 516552, so it just missed the cut-off.
,
Dec 20 2017
This memory leak was gone in Beta M63 but it seems to be back in M64 64.0.3282.24 (Or there's a different leak with similar symptoms). |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by ligim...@chromium.org
, Nov 1 2017Labels: Needs-Triage-M63