Closed Bug 834196 Opened 12 years ago Closed 12 years ago

Huge memory leak in Firefox 17 ESR

Categories

(Firefox :: Untriaged, defect)

17 Branch
x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: firefox.ewg, Unassigned)

Details

(Whiteboard: [MemShrink:P3])

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.12) Gecko/20100101 Firefox/10.0.12 Build ID: 20130103094221 Steps to reproduce: FF ESR 17.0.2 installed via a DMG (OS X), from previous (FF ESR v10.0.11) version - so not via auto-update (which doesn't work well for us, so we manually upgrade each time re-using the user profles). Actual results: Users shortly afterwards reported slowing down of Macs, even those with large memory that never page were paging HUGE amounts, for example one FF ESR v17.0.2 was paging 25.6GB (yes GigiBytes) on a MacPro that never in normal usage pages, ever. Even after closing all other applications, FF caused paging. Expected results: Normal usage of FF should not result in paging on these Macs, ever. For comparison, FF ESR v10.0.12 is not paging (and has a Virtual Memory footprint of around 870MB for the same pages being displayed as above).
You'll need to provide more information. Does this happen on every page, or just some particular ones? Can you provide the contents of about:memory?verbose (type it in the urlbar)?
Thanks for the rapid response Tim, this is my first bug report, so bear with me (it was due to the seriousness of the bug that we are reporting it, our first time doing so). I've had to remove all instances of FF ESR v17.0.2 so will have to set aside a test Mac to reproduce it to gather the additional info you ask for - however: This problem happened on every single Mac after the FF ESR v17.0.2 update, some taking longer than others to show the problem. All Firefox instances (tend to be) left open day after day, to avoid the cost of getting back to where they are each day, until this bug we rarely have problems running for up to about a week at a time. The bug shows up faster on certain web sites, such as ebay, for example when opening 10's of ebay auction pages, and leaving them open for (say) overnight.
As Tim said, post a memory log from about:memory?verbose when the leak is present. In addition, try in safe mode (https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode), it could be an issue with one of your add-ons. (you can launch a specific profile in safe mode and wait for a few hours no need to use it)
Whiteboard: [MemShrink]
Thank you Loic (& Tim), your help is appreciated. The results so far suggest a problematic addon/plugin interaction. Our standard FF esr configuration uses 17 addons from the Firefox (https://addons.mozilla.org/en-US/firefox/) addons.mozilla.org public web site, one (1) custom extension, and 10 plug-ins mostly supplied with other software (such as MS office, Adobe Flash, etc.). We are trying to narrow down which combination (addpon/plugin) causes the paging, but it seems likely a 'plain vanilla' Firefox install will be fine, as the Mac with FF in safe mode had no problems - ok it's only a single Mac run for under 24 hours, but previously the problem would have exhibited with 6-8 hours, hence this update on progress - to avoid anyone else wasting time if it's an addon/plugin issue. Will update this in a couple of days time, when we have conducted more tests, again, many thanks for the guidance so far (any additional suggestions or help welcomed).
about:compartments (section "ghost windows") might help if some add-ons keep references in memory on closed tabs.
I don't suppose you're playing html5 video? This reminds me of bug 834667.
Summary: Huge memory leak → Huge memory leak in Firefox 17 ESR
Steps to reproduce would be great, here.
Whiteboard: [MemShrink] → [MemShrink:P3]
Flags: needinfo?(firefox.ewg)
Am having problems chasing this FF bug; have removed ALL FF add-ons and plug-ins; have tried to reproduce it, but can't find a reliable method of reproducing - it most commonly happens on a Mac with: a) run the old FF ESR v10.0.12 run then close; b) manually upgrade from the ESR release DMG to FF ESR v17; c) use normally, without closing for several days; d) occasionally for no (to me, anyway) apparent reason FF will go memory-mad acquiring a huge memory allocation that causes massive paging (on Macs that normally never,ever page, ever) as shown in the attachment. The attached screen-shot shows such an incidence today; note, FF refuses to respond so I'm unable to supply the about:memory?verbose as requested, as FF had stalled at this point (after being left overnight without be closed, nor (actively) used). Nothing I did gained any further response from FF (ie the 'not responding' as reported in the screen-shot is very accurate). I closed all other open applications, which freed up some ram, but FF never recovered or responded even after being left an hour - eventually had to force-quit FF and reboot, fsck, etc. to ensure a clean OSX again afterwards. As I'm unable to get useful info when this happens, nor say exactly how to reproduce the bug, there seems little to be gained by pursuing it further (I'd had to admit in writing just how many hours I've spent on this problem). I'll look back for a day or two in case anyone has any helpful suggestions or advice, otherwise it seems best to 'just hope it goes away' and until then, we'll stick to the reliable and well behaved FF ESR v10.0.2 here. Thanks all.
Flags: needinfo?(firefox.ewg)
With ESR 17.0.3? If that also fails, would you be able to use a non-ESR aurora or beta build?
Flags: needinfo?(firefox.ewg)
@Loic, thanks for your suggestions, that helped exclude the plug-ins from being the cause by monitoring the memory as each was added back again. @njn, whilst some video was being played that was rare (during break times, by some, but by no means all concerned) @Wayne, sadly it wasn't clear whether ESR 17.0.3 was fixed, or not, however read on: @All: Since ESR 17.0.4 we have not had a single occurrence of this problem, which is why the response was so long, it's hard to prove a negative, only time and heavy use give any confidence in making any such comment, and only recently did we reach that level of confidence here. Summary: Somewhere after ESR 17.0.2 we found the problem has gone away, but due to the roll-out not being very well coordinated with problem reports, it's not clear which version included the fix. Thanks all for the help and your patience, we are now back to being happy Firefox campers with Firefox ESR 17.0.6 the current version used here with no problems at all - excellent!
Flags: needinfo?(firefox.ewg)
Thanks for the feedback, feel free to reopen it if the issue is back.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Glad to hear it's fixed. You're right that sometimes it's hard to know exactly what fixed a problem, esp. with ESR releases.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: