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)
Tracking
()
RESOLVED
DUPLICATE
of bug 1287547
People
(Reporter: alexandrexavier, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [MemShrink:P3])
Attachments
(3 files)
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.
Reporter | ||
Updated•8 years ago
|
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
Comment 1•8 years ago
|
||
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.
Reporter | ||
Comment 2•8 years ago
|
||
OK. I downloaded 50.0a1 and disabled e10s. Should I keep e10s enabled?
Comment 3•8 years ago
|
||
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.
Reporter | ||
Comment 4•8 years ago
|
||
firefox 50.0a1
Reporter | ||
Comment 5•8 years ago
|
||
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•8 years ago
|
||
Hi Eric, can you take a look at this bug? Where this bug should land? Thanks
Flags: needinfo?(erahm)
Comment 7•8 years ago
|
||
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]
Reporter | ||
Comment 8•8 years ago
|
||
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
Reporter | ||
Comment 9•8 years ago
|
||
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
Reporter | ||
Comment 10•8 years ago
|
||
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.
Reporter | ||
Comment 11•8 years ago
|
||
Firefox in safe mode
Reporter | ||
Comment 12•8 years ago
|
||
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•8 years ago
|
||
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)
Comment 15•8 years ago
|
||
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)
Comment 16•8 years ago
|
||
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.
Reporter | ||
Comment 17•8 years ago
|
||
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?
Reporter | ||
Comment 18•8 years ago
|
||
(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 20•8 years ago
|
||
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)
Updated•8 years ago
|
Blocks: GhostWindows
Comment 21•8 years ago
|
||
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]
Reporter | ||
Comment 22•8 years ago
|
||
Ok, but you'll have to wait a couple of weeks before I can do anything because I can't do this right now.
Updated•8 years ago
|
Summary: Firefox doesn't clean up its memory → High memory usage and ghost windows present
Reporter | ||
Comment 23•8 years ago
|
||
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•8 years ago
|
||
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
Updated•8 years ago
|
Flags: needinfo?(erahm)
Comment 25•8 years ago
|
||
Andrew, looks like we've got a verbose log in comment 23, can you take a look?
Flags: needinfo?(erahm) → needinfo?(continuation)
Comment 26•8 years ago
|
||
I've downloaded the log. I'll take a look.
Comment 27•8 years ago
|
||
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
Comment 28•8 years ago
|
||
None of those obviously look like they could be script elements.
Updated•8 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 29•8 years ago
|
||
Boris, do you have any ideas as to what might be holding a PersistentRooted to a ScriptElement reflector?
Flags: needinfo?(continuation) → needinfo?(bzbarsky)
Comment 30•8 years ago
|
||
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)
Updated•8 years ago
|
Priority: -- → P2
Comment 31•8 years ago
|
||
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
Reporter | ||
Comment 32•8 years ago
|
||
I won't be able to test this within the next months.
Comment 33•8 years ago
|
||
> 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•8 years ago
|
||
(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 →
Assignee | ||
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•