Issue metadata
Sign in to add a comment
|
[M58] When discarding two tabs sharing a renderer, memory is not freed |
||||||||||||||||||||||||
Issue description
When a renderer process contains two tabs, discarding both tabs doesn't seem to
free up the memory of either.
[Note -- I use two URLs here: '1000MB.html' and '100MB.html'. These pages
allocate large Uint8Array in a <script> in the body and store a reference to the
memory in a global var. Other than consuming a distinct amount of memory, these
could be any webpage.]
Initial set-up:
1. Launch chrome.exe with:
--disable-extensions --renderer-process-limit=3
Why these flags: N=3 let us simulate hitting the at-process-limit scenario
without needing to create lots of tabs. --disable-extensions removes the
effect of extensions, which count against the total process limit. If you
don't run with these flags, the steps below should probably still work,
you'll just have to create a lot more tabs in step 2 before sharing kicks
in.
2. Create tabs opened to the following URLs, in order:
chrome://discards/
https://nick-chromium.github.io/100MB.html
https://nick-chromium.github.io/100MB.html
https://nick-chromium.github.io/1000MB.html
3. In the TaskManager, there should now be one process that has two tabs in it;
it has one '100MB' and one '1000MB' page. There should also be another
process with just a singleton '100MB' tab.
4. Close one of the 100MB tabs so that you're left with one renderer process
that contains both a '100MB' and '1000MB' tab (leave the chrome://discards/
tab around too)
5. The process shared by the 100MB & 1000MB tabs should show more than 1100MB
of memory use.
Trigger the bug:
6. Write down the process ID of the 1100MB process, and locate this process in
the OS (not Chrome's built-in) task manager.
7. Activate the chrome://discards tab, and hit reload.
8. Discard the 100MB tab.
9. Discard the 1000MB tab.
ACTUAL RESULT: (In M58), the process remains around and visible in the Chrome
Task Manager, and consumes more than 1100MB of memory.
ACTUAL RESULT: (In M61), the process is hidden from Chrome's task manager, but
remains alive and visible in the OS task manager. It only consumes 20MB of memory (it looks like there was a GC after a few seconds).
EXPECTED RESULT: the process should have been killed. If it isn't killed, it
should report less than 100MB of memory use.
,
Jun 26 2017
Looks like there was an earlier bug for this with less deterministic repro steps: issue 450876 . We should continue discussion here and get this fixed.
,
Jul 5 2017
Issue 450876 has been merged into this issue.
,
Jul 5 2017
,
Jul 11 2017
,
Jul 11 2017
,
Jul 12 2017
As far as I know, there's nothing Windows specific about this bug, and it was only marked OS-Windows because it was discovered there. I'll mark it OS-All until we can narrow down which platforms it actually affects.
,
Jul 13 2017
Do we know if it affects anything beyond M58 ? I will try to reproduce this on Chrome OS when I get a chance
,
Jul 13 2017
I tried on ToT (M61) Chrome OS with max renderers set to 3 and a large number of tabs sharing the same renderer and was able to observe the discarder kick tabs out of there and avoid hitting a kernel OOM kill. So that makes me think discarding shared tabs is working at least somewhat on ToT. I will try to reproduce on M58 and see if the behavior is different.
,
Jul 13 2017
(re-add avi)
,
Jul 13 2017
(re-add nick@, apparently adding to the beginning of the list of cc is bad?)
,
Jul 13 2017
I actually can reproduce the issue on M58 Chrome OS where discarding the shared tabs doesn't seem to free up any memory and I hit a kernel OOM kill eventually. So something changed between R58 and R61 that fixed the issue.
,
Jul 13 2017
59 seems to work properly for the most part (I occasionally can get OOM kills but usually not)
,
Jul 15 2017
FYI I'm trying to bisect this on CrOS now
,
Aug 1 2017
I was unexpectedly out for a few weeks and R58 is no longer current stable. I'm going to close this as WontFix since I don't think it happens on R59 Re-open if necessary
,
Aug 1 2017
In M59 and later, is the process still around after all of its tabs are discarded? That's what the original report says for M61, and I would still consider that a leak (of 20MB as described). That's not as bad as in M58, but shouldn't we still fix that? If I'm wrong and that's by design (or not repro'ing), then feel free to close again.
,
Aug 2 2017
re #16 -- I haven't seen that on CrOS but I can double check.
,
Aug 3 2017
I think I was able to reproduce something like this on R59 where there were two tabs in a renderer and both were discarded but the process stuck around. It looks like that process was using about 30MB. I will check to see if this still happens on ToT
,
Aug 4 2017
It does happen on ToT and it seems that this has been the behavior for a long time -- at least a few years -- as there's actually another bug already covering this that was filed over 3 years ago: crbug.com/348007 I'm going to dup to that bug |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by nick@chromium.org
, Jun 26 2017