1279757 - High memory usage and ghost windows present

Status: RESOLVED DUPLICATE of bug 1287547

(Core :: DOM: Core & HTML, defect, P2)

Description

[Alexandre-Xavier]

Attachment: firefox_ram.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20151223140742

Steps to reproduce:

Used FireFox for three days without closing it and watched videos. Went on Facebook. 


Actual results:

Firefox uses a lot of RAM. If I close my tabs, it doesn't clean up its memory. 


Expected results:

FireFox should use less RAM.

Comment 1

[Pascal Chevrel:pascalc]

Hi, can you reproduce on a supported version of Firefox? You are using 43 and we just released 47, ideally testing on Firefox 50 with process separation activated in preferences (e10s) would be more useful to know if the problems still exists for your configuration with the upcoming versions of Firefox. Thanks.

Comment 2

[Alexandre-Xavier]

OK. I downloaded 50.0a1 and disabled e10s. Should I keep e10s enabled?

Comment 3

[Pascal Chevrel:pascalc]

You should probably keep e10s activated, Firefox 43 doesn't have e10s and e10s will be soon the default mode for Firefox. If you experience a memory leak like before, what you can try is go to about:memory, click on measure and try to identify what is leaking memory in what is displayed (there is documentaition here https://developer.mozilla.org/en-US/docs/Mozilla/Performance/about:memory). What developers need to make this bug actionable are steps to reproduce the memory leak you are experiencing on the latest version of Firefox.Thanks.

Comment 4

[Alexandre-Xavier]

Attachment: memory-report.json.gz

firefox 50.0a1

Comment 5

[Alexandre-Xavier]

I added a memory report. "explicit" shows the same amount of memory that I can see in my task manager. I have only the "about:memory" tab open and the tab of this bug report. The memory doesn't seem to leak, but Firefox uses a huge amount of memory for just two tabs. That means a lot of stuff remains in memory and it probably doesn't need to.

Comment 6

[ovidiu boca[:Ovidiu]]

Hi Eric, can you take a look at this bug? Where this bug should land? Thanks

Comment 7

[Eric Rahm [:erahm]]

Looks like a fair amount of ghost windows sticking around:

> 14 (100.0%) ++ ghost-windows

This is often related to add-ons. Alexandre-Xavier, can you attach the contents of 'about:support'? This should give us an idea of what add-ons are enabled and if any preferences might be involved.

Further you might want to try disabling add-ons to see if that helps. You can perform a quick check to see if add-ons are responsible by running in safe mode [1].

[1] https://support.mozilla.org/kb/troubleshoot-firefox-issues-using-safe-mode

Comment 8

[Alexandre-Xavier]

Here is the content of about:support. I have "Adblock Plus" and "Ubuntu Firefox Modifications". I will try in safe mode and come back in three days.
*************************************************************************************

Application Basics
------------------

Name: Firefox
Version: 50.0a1
Build ID: 20160621001311
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
OS: Linux 3.19.8-031908-generic
Multiprocess Windows: 1/1 (Enabled by user)
Safe Mode: false

Extensions
----------

Name: Adblock Plus
Version: 2.7.3
Enabled: true
ID: {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}

Name: Firefox Hello
Version: 1.4.0
Enabled: true
ID: [e-mail]

Name: FlyWeb
Version: 1.0.0
Enabled: true
ID: [e-mail]

Name: Multi-process staged rollout
Version: 1.0
Enabled: true
ID: [e-mail]

Name: Pocket
Version: 1.0.3b1
Enabled: true
ID: [e-mail]

Name: Ubuntu Firefox Modifications
Version: 3.0
Enabled: true
ID: [e-mail]

Name: Web Compat
Version: 1.0
Enabled: true
ID: [e-mail]

Graphics
--------

Features
Compositing: Basic
Asynchronous Pan/Zoom: wheel input enabled
WebGL Renderer: nouveau -- Gallium 0.4 on NVD9
Hardware H264 Decoding: No
GPU #1
Active: Yes
Description: nouveau -- Gallium 0.4 on NVD9
Vendor ID: nouveau
Device ID: Gallium 0.4 on NVD9
Driver Version: 3.0 Mesa 10.3.2

Diagnostics
AzureCanvasAccelerated: 0
AzureCanvasBackend: skia
AzureContentBackend: cairo
AzureFallbackCanvasBackend: none
CairoUseXRender: 0
Decision Log
HW_COMPOSITING:
blocked by default: Acceleration blocked by platform




Important Modified Preferences
------------------------------

accessibility.typeaheadfind.flashBar: 0
browser.cache.disk.capacity: 358400
browser.cache.disk.filesystem_reported: 1
browser.cache.disk.smart_size.first_run: false
browser.cache.disk.smart_size.use_old_max: false
browser.cache.frecency_experiment: 1
browser.download.importedFromSqlite: true
browser.download.useDownloadDir: false
browser.places.smartBookmarksVersion: 8
browser.sessionstore.upgradeBackup.latestBuildID: 20160621001311
browser.startup.homepage_override.buildID: 20160621001311
browser.startup.homepage_override.mstone: 50.0a1
browser.tabs.remote.autostart: true
browser.tabs.remote.autostart.2: false
dom.apps.lastUpdate.buildID: 20160621001311
dom.apps.lastUpdate.mstone: 50.0a1
dom.apps.reset-permissions: true
extensions.lastAppVersion: 50.0a1
general.autoScroll: true
media.gmp-gmpopenh264.abi: x86_64-gcc3
media.gmp-gmpopenh264.lastUpdate: 1465787847
media.gmp-gmpopenh264.version: 1.5.3
media.gmp-manager.buildID: 20160618024606
media.gmp-manager.lastCheck: 1466459078
media.gmp.storage.version.observed: 1
network.cookie.prefsMigrated: true
network.predictor.cleaned-up: true
places.database.lastMaintenance: 1466492362
places.history.expiration.transient_current_max_pages: 104858
plugin.disable_full_page_plugin_for_types: application/pdf
plugin.importedState: true
services.sync.declinedEngines:
storage.vacuum.last.index: 1
storage.vacuum.last.places.sqlite: 1465793555

Important Locked Preferences
----------------------------

Places Database
---------------

JavaScript
----------

Incremental GC: true

Accessibility
-------------

Activated: false
Prevent Accessibility: 0

Library Versions
----------------

NSPR
Expected minimum version: 4.12
Version in use: 4.12

NSS
Expected minimum version: 3.25
Version in use: 3.25

NSSSMIME
Expected minimum version: 3.25
Version in use: 3.25

NSSSSL
Expected minimum version: 3.25
Version in use: 3.25

NSSUTIL
Expected minimum version: 3.25
Version in use: 3.25

Experimental Features
---------------------

Sandbox
-------

Seccomp-BPF (System Call Filtering): true
Seccomp Thread Synchronization: true
User Namespaces: true
Media Plugin Sandboxing: true

Comment 9

[Alexandre-Xavier]

I opened this link: http://www.journaldemontreal.com/2016/06/22/une-parodie-de-pied-de-poule-sur-la-controverse-des-pitbulls

I got a huge memory leak. I have been able to reproduce it twice, but failed thereafter. The leak was in the thread "plugin-container". I'm in safe mode, so Flash is disabled. 

Picture album (4 pics): http://imgur.com/a/lRMEI

Comment 10

[Alexandre-Xavier]

Someone closed the browser (I'm not the only one on this computer). 

I will have to wait again so that the browser's memory gets filled.

Comment 11

[Alexandre-Xavier]

Attachment: memory-report-safemode.json.gz

Firefox in safe mode

Comment 12

[Alexandre-Xavier]

New attachment. Firefox running in safe mode. (memory-report-safemode.json.gz)

Resource monitor reports 1.1 GB of RAM use for "Web Content" and 417 MB for "firefox-trunk". 
LxTask reports 1.3 GB of RAM use for "Web Content" and 586 MB for "firefox-trunk".

Comment 13

[Eric Rahm [:erahm]]

We're still seeing ghost windows in safe mode, khuey is there any other info that would be helpful here?

> 20 (100.0%) -- ghost-windows

Comment 14

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Cycle collection logs would be the next step here.

Comment 15

[Eric Rahm [:erahm]]

Alexandre-Xavier, thank you for you help in debugging this. When you see many 'ghost-windows' in your about:memory log can you also run run 'Save GC & CC logs' -> 'Save concise' and attach the results here? That will help us figure out why your closed windows are sticking around.

Comment 16

[Andrew McCreight [:mccr8]]

Note that these logs will contain a lot of personal data from your browser session. So you may want to try to reproduce the issue in a clean profile.

Comment 17

[Alexandre-Xavier]

I closed my tabs, except the about:memory tab and the ghost windows disappeared. The firefox-trunk process still uses 350 MB of RAM and 50 MB for "Web Content (System monitor). LxTask reports 480 MB for firefox-trunk and 160 MB for "Web Content". I think this is too much. 

Should I still "run 'Save GC & CC logs' -> 'Save concise'" even though the ghost windows are gone?

Comment 18

[Alexandre-Xavier]

(In reply to Eric Rahm [:erahm] from comment #15)
> Alexandre-Xavier, thank you for you help in debugging this. When you see
> many 'ghost-windows' in your about:memory log can you also run run 'Save GC
> & CC logs' -> 'Save concise' and attach the results here? That will help us
> figure out why your closed windows are sticking around.

I did what you said. Here's the file. The is only one ghost window, but there have been others that disappeared. 

http://www.mediafire.com/download/74zp4pl2z6lub5a/Save-concise.7z

Comment 19

[Eric Rahm [:erahm]]

Andrew can you take a look at the CC log?

Comment 20

[Andrew McCreight [:mccr8]]

The about:memory log in that file has a ghost-window for doubleclick.net, but unfortunately I don't see anything related to doubleclick.net in the CC log, so I won't be able to figure out anything from them. A verbose log might be useful, but it might also be too big to really deal with uploading.

Comment 21

[Eric Rahm [:erahm]]

Alexandre-Xavier, if you can redproduce with many ghost windows that would be helpful. Additionally getting a verbose cc log might help in that situation. The file can be rather large, it's possible you can mail it directly to Andrew or myself.

Comment 22

[Alexandre-Xavier]

Ok, but you'll have to wait a couple of weeks before I can do anything because I can't do this right now.

Comment 23

[Alexandre-Xavier]

I got a verbose but only one ghost window. This is a short web session. I will try to get more soon.

http://www.mediafire.com/download/he34l2nattk1951/verbose.7z

Comment 24

[ovidiu boca[:Ovidiu]]

Eric can you please take a look at comment 23 and see if Alexandre post help you with this bug, and also can you please advice me what component should fit for this issue? Thanks

Comment 25

[Eric Rahm [:erahm]]

Andrew, looks like we've got a verbose log in comment 23, can you take a look?

Comment 26

[Andrew McCreight [:mccr8]]

I've downloaded the log. I'll take a look.

Comment 27

[Andrew McCreight [:mccr8]]

The ghost window is being held alive via its reflector, which is being held alive in turn like this:

via persistent-Object :
0x7f1beeb85a90 [HTMLScriptElement <no private>]
    --[shape]--> 0x7f1beebf71f0 [shape]
    --[base]--> 0x7f1c1fdc48a8 [base_shape]
    --[global]--> 0x7f1bf726e560 [Window <no private>]

This means there is some field, presumably of a class in dom/, that is holding a strong reference to the reflector of an HTMLScriptElement, which is holding alive the window global.

I think it must be one of these:
http://searchfox.org/mozilla-central/search?q=PersistentRooted%3CJSObject&path=dom

Comment 28

[Andrew McCreight [:mccr8]]

None of those obviously look like they could be script elements.

Comment 29

[Andrew McCreight [:mccr8]]

Boris, do you have any ideas as to what might be holding a PersistentRooted to a ScriptElement reflector?

Comment 30

[Boris Zbarsky [:bzbarsky]]

Hmm.  Looking at uses of PersistentRooted<JSObject*> and PersistentRootedObject, the only one that looks like it ought to ever end up with a ScriptElement in it is an element of CycleCollectedJSContext::mPreservedNurseryObjects.  Though presumably if that's it then it would get cleared at the next collection end?

None of the other ones look like they could ever have a script element in them at first glance.

Comment 31

[Ben Kelly [:bkelly, not reviewing]]

Looks very similar to bug 1287547 which was fixed in FF50 on July 26.  That's 3 days before comment 23.  Its likely this is a dupe.

Alexandre, can you still reproduce with a recent FF50+?

Comment 32

[Alexandre-Xavier]

I won't be able to test this within the next months.

Comment 33

[Boris Zbarsky [:bzbarsky]]

> Looks very similar to bug 1287547 which was fixed in FF50 on July 26. 

Oh, I _knew_ the PersistentRooted to an HTMLScriptElement thing sounded familiar!  

I expect that at least that part of this bug is in fact bug 1287547.

Comment 34

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Alexandre-Xavier from comment #32)
> I won't be able to test this within the next months.

Ok.  Due to the similarities and the timeframe I'm going to go ahead and dupe this.  If you see it again, please feel free to reopen or file a new bug.  Sorry for the issues and thanks for the report!