New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 711934 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 718484
Owner:
Last visit > 30 days ago
Closed: May 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug


Show other hotlists

Hotlists containing this issue:
Hotlist-1


Sign in to add a comment

Garbage-collection fails to release memory used by closed pages of extensions with a persistent background page

Reported by woxxom@gmail.com, Apr 15 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36

Steps to reproduce the problem:
Simplified repro:
1. install the attached extension, open Chrome Task Manager (Shift-Esc key) and observe the extenion's memory usage
2. click the installed extension's toolbar icon and observe memory usage
3. close the 4 tabs opened by the extension and observe memory usage

Generic description of the repro:
1. Declare a persistent background page in an extension
2. Open an extension page with lots of DOM nodes in a new tab
3. Close that tab

What is the expected behavior?
step 1: 15 MB
step 2: 275 MB
step 3: 15 MB within 1 minute

What went wrong?
step 1: 15 MB
step 2: 275 MB
step 3: 150 MB - this is 10 times more than the expected amount and it doesn't shrink

Did this work before? No 

Chrome version: 57.0.2987.133  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 25.0 r0

A. Each repetition of the repro cycle increases the amount of memory not being released.

B. Manually triggering garbage collection reduces the memory usage to 27 MB after one repro cycle, which isn't the expected 15 MB, but at least it's a more reasonable amount. To trigger the GC manually: 1. open chrome://extensions page 2. enable Developer mode checkbox, 3. click the extension's background page 4. switch to Memory panel (or Timeline) 5. click the garbage bin icon

C. Using a non-persistent event page is not a viable option for lots of scenarios, particularly when using webRequestBlocking.

D. An extension doesn't even have any means to detect the memory isn't being released, otherwise it could have reloaded itself via chrome.runtime.reload()
 
memory-constipation.zip
1.3 KB Download
Labels: Needs-Triage-M57
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on Windows 10 using chrome version 57.0.2987.133, Observed the Memory percentage is showing 150 in Task manger after closing the 4 tabs.

Observed the same behavior since #30.0.1549.0, Hence marking this issue as untriaged.

Thanks,

Comment 3 by bokan@chromium.org, Apr 19 2017

Components: -Blink Platform>Extensions Blink>JavaScript>GC
Cc: hpayer@chromium.org jgruber@chromium.org
Status: Available (was: Untriaged)
memory sheriffs on cc, PTAL

Comment 5 by hpayer@chromium.org, Apr 24 2017

Cc: -hpayer@chromium.org
Owner: hpayer@chromium.org
We have a Chrome extension that is leeking massive amounts of memory. I have heap snapshots showing what I think are memory leaks by Chrome, loads of people are reporting crashing extensions and extreme memory use. 

This issue seems to be similar. Opening and closing the extension popup many times keeps adding memory according the task manager, and it goes down really slowly.

Screenshot 2017-04-24 14.19.57.png
56.5 KB View Download
Status: Started (was: Available)
It seems that there is a regression in context disposal. A GC should be scheduled when closing the tabs.

Comment 8 by w...@chromium.org, May 5 2017

Do we think this is a distinct from  issue 718484 ?
Mergedinto: 718484
Status: Duplicate (was: Started)
Thanks for the great repro case! This issue should be fixed now.

Sign in to add a comment