Closed Bug 1279757 Opened 8 years ago Closed 8 years ago

High memory usage and ghost windows present

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Version:
43 Branch
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1287547

People

(Reporter: alexandrexavier, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [MemShrink:P3])

Attachments

(3 files)

firefox_ram.png
396.22 KB, image/png
Details
memory-report.json.gz
727.62 KB, application/gzip
Details
memory-report-safemode.json.gz
356.96 KB, application/gzip
Details
Attached image 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.
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
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.
OK. I downloaded 50.0a1 and disabled e10s. Should I keep e10s enabled?
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.
Attached file memory-report.json.gz — 
firefox 50.0a1
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.
Hi Eric, can you take a look at this bug? Where this bug should land? Thanks
Flags: needinfo?(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
Flags: needinfo?(erahm) → needinfo?(alexandrexavier)
Whiteboard: [MemShrink]
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: loop@mozilla.org

Name: FlyWeb
Version: 1.0.0
Enabled: true
ID: flyweb@mozilla.org

Name: Multi-process staged rollout
Version: 1.0
Enabled: true
ID: e10srollout@mozilla.org

Name: Pocket
Version: 1.0.3b1
Enabled: true
ID: firefox@getpocket.com

Name: Ubuntu Firefox Modifications
Version: 3.0
Enabled: true
ID: ubufox@ubuntu.com

Name: Web Compat
Version: 1.0
Enabled: true
ID: webcompat@mozilla.org

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
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
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.
Firefox in safe mode
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".
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
Flags: needinfo?(alexandrexavier) → needinfo?(khuey)
Cycle collection logs would be the next step here.
Flags: needinfo?(khuey)
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.
Flags: needinfo?(alexandrexavier)
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.
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?
(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
Andrew can you take a look at the CC log?
Flags: needinfo?(continuation)
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.
Flags: needinfo?(continuation)
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.
Flags: needinfo?(alexandrexavier)
Whiteboard: [MemShrink] → [MemShrink:P3]
Ok, but you'll have to wait a couple of weeks before I can do anything because I can't do this right now.
Summary: Firefox doesn't clean up its memory → High memory usage and ghost windows present
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
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
Flags: needinfo?(erahm)
Andrew, looks like we've got a verbose log in comment 23, can you take a look?
Flags: needinfo?(erahm) → needinfo?(continuation)
I've downloaded the log. I'll take a look.
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
Component: Untriaged → DOM
Product: Firefox → Core
None of those obviously look like they could be script elements.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Boris, do you have any ideas as to what might be holding a PersistentRooted to a ScriptElement reflector?
Flags: needinfo?(continuation) → needinfo?(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.
Flags: needinfo?(bzbarsky)
Priority: -- → P2
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+?
Flags: needinfo?(alexandrexavier)
See Also: → 1287547
I won't be able to test this within the next months.
> 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.
(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!
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(alexandrexavier)
Resolution: --- → DUPLICATE
See Also: 1287547 →
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: