New issue
Advanced search Search tips

Issue 733735 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Jun 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug

Blocking:
issue 733323



Sign in to add a comment

Potential memory leak of extension FeatureProviders

Project Member Reported by erikc...@chromium.org, Jun 15 2017

Issue description

I've been running Chrome with memory profiling enabled. I started with a gmail tab that I used for ~2 weeks. Then I forced a GC, navigated to about:blank, and then forced another GC. The renderer that was hosting the about:blank frame still has ~6 thousand feature providers that have not been destroyed. These stats come from a renderer that is only hosting about:blank.

Raw & processed data: https://bugs.chromium.org/p/chromium/issues/detail?id=733323#c2
Methodology: https://docs.google.com/document/d/1fN5balfyrd7sRpd6DRaUI1TwoOwYjLyRSd7mwZT5US8/edit#

Each screenshot shows:
  1) # of objects created [that have not been destroyed]
  2) The stack trace of the code that created the object.

1) This seems like a large number of feature providers to have around...maybe an issue with the caching logic?
2) I don't think we still need this many feature providers after hitting about:blank, right? Maybe we should try to clear the cache at reasonable points in time?
 
Screen Shot 2017-06-15 at 11.12.46 AM.png
205 KB View Download
Actually, feature providers are a core part of the extension permissions system, and can be necessary in any renderer (including about:blank).  Given this, and that they are non trivial to construct (though significantly faster than they used to be!), we never collect them, by design.

But... is that number at the top (6594) the number of feature providers?  If so, that's... wildly wrong.  There should only be 4 per process, and they are stored in a leaky lazy instance.  Does that object count include objects owned by the feature providers?
Status: WontFix (was: Untriaged)
Whoops, good catch. In this case, there was elision of a bunch of small allocations [observed by the fact that we don't actually see a call to new or malloc at the top of the trace], and all objects were glommed together.

Sign in to add a comment