Cyberpawz.

Rather a long thread but I know you repeatedly mentioned Ghostery, and then the fact that you did update Ghostery.

Did that solve or at least improve your Memory problems.
I realise of course there is still an open bug

• Bug 896016 - Investigate why Firefox reaches 2-3 GB of heap-unclassified on OSX very quickly (~10 mins)

Everyone.

As you can see from the posts for at least some users the solution to this or a similar problem is to update Ghostery.

Note we often suggest

• listing all extensions
  See also Use the Troubleshooting Information page to help fix Firefox issues
• starting your own thread (maybe cross linking it) and following the prompts to include full trouble shooting information
  use /questions/new
• testing Firefox in safemode with a clean profile and all plugins disabled.

It would seem that Ghostery might just be the culprit for this issue, particularly v5.0.1 -- they have confirmed some sort of problem that is being beta-tested at present. See this thread:

http://getsatisfaction.com/ghostery/topics/very_high_cpu_usage_and_memory_utilization_with_ghostery_5_0_1_for_firefox

There is now a final v5.0.2 which is available from the Firefox add-ons webpages.

@ Jhvance

Yeah, unfortunately the owner of this thread and another poster have confirmed this problem happens for each of them with zero addons installed and have tried new profiles. And they're both on mac, which makes me think this is a mac only memory bug.

I just saw your other thread now. Sorry about that. I should've asked you to send me a link to it. So I missed it. I had a feeling you had Ghostery installed. The last couple of releases have been causing high memory on both Windows & Mac.

So does uninstalling it fix your memory problem at least? Anyway, I'll continue talking to you in your thread.

My version was originally without Ghostery... and even with the latest version it's still a situation. Ghostery had a known memory leak and I could deal with that, because it was to be fixed at a patched date. Firefox has yet to be... at least on the Mac...

The PC side, well, I still don't know.

For the past couple of days after upgrading to FF v23.0, I've experienced about 10 outright crashes of the browser with Ghostery v5.0.1 running. However, since upgrading to v5.0.2beta and then to the final v5.0.2, I haven't had any crashes and the FF memory load seems to be reasonably stable, but it's still at 300Mb so it would really be nice to see a decline in that load factor in the next release.

Cyberpawz,
Thanks for the replies. I know some of you are chatting on IRC and looking into an open bug and I was wondering what the latest status of this was.

Cross referencing.

jhvance
I note

• You use Windows
• have open bug Bug 893943 - Webpage conflict causes Firefox to become nonresponsive and requires manual termination of process in Task Manager.
• and started thread memory

I know this is a late comment but we did confirm that the Windows and Mac versions of Firefox share the same core. So, it is highly likely that the memory leak is in a common component and that fixing that memory leak will fix it for both the Windows and Mac versions.

curmudgeon99,

it is highly likely that the memory leak is in a common component and that fixing that memory leak will fix it for both 

True enough it may be a bug that affects both OS and has not otherwise been reported.

There could well be multiple issues in this thread even without considering there are two different OS involved

1. Ghostery memory leak that is apparently fixed by upgrading from5.0.1
2. Your leak noticed (& ? reproducible) when using a particular site (Bug 896016)
3. A long standing issue the OP is observing even without Ghostery, and presumably not using the same site as you. (Initial reason for bug 896016)
4. An issue with Windows (Bug 893943)
5. Possibly yet others from various posters

I view any Add-On-related issue as orthogonal to my problem since my and another another user's issue occurs with no add ons ever installed.

I have never mentioned it until now but I know of a Windows FF user using that site who experiences the exact same problem.

Since the source of this memory leak is as yet unknown, I think it is premature to tie it to any one OS. You cannot characterize an unknown.

Finally, given that we have confirmed that the majority of the FF code base is common to both Windows & OS X, trying to blame one OS is a distinction without a difference.

Hi curmudgeon99

I have never mentioned it until now but I know of a Windows FF user using that site who experiences the exact same problem. 

Have you tried to ask that Windows user to collect about:memory data as in Noah's suggestion above

I view any Add-On-related issue as orthogonal to my problem since my and another another user's issue occurs with no add ons ever installed. 

So as I said multiple separate issues.

• You possibly have not yet demonstrated the issue other than on one particular site.
• The OP has a long standing problem and probably has never visited the site you have a problem on.
• the developers working on memory issues are I believe tracking about 400 bugs, some of those are improvements or tools others are issue fixes.

All I was trying to do was figure out was if any of these issues

• were found to be reproducible
• had developed to a point where a workaround or solution may be available

Other than the issue with Ghostery it appears there is not really any news at the moment.

I have mitigated the impact of the issue by bumping up the RAM on my OS X box to 16GB. I have also turned off automatic updates of FF until this issue gets resolved.

I mitigated the issue by switching to safari. Keeping an eye on this thread though just in case it gets sorted.

I participated in the creation of a bug, so I certainly will keep an eye on this one. But the bump up in RAM had other benefits besides giving FF more "Lebensraum."

I have mitigated the impact of the issue by bumping up the RAM on my OS X box to 16GB.

With one of the reports mentioning ".... Firefox reaches 2-3 GB of heap-unclassified on OSX very quickly (~10 mins)"
That may be expected to buy you up to about another another 140 minutes.
Or maybe in your case it does not increase continuously at that rate, or never exceeds some particular threshold. Others of course may have different root causes for the memory issues and slightly different typical behaviour.

I have also turned off automatic updates of FF until this issue gets resolved. 

That does not sound like a workaround generally suitable.

1. Old versions are insecure and unsupported.
2. The intent is that they are also improvements over prior versions.
3. How will you ever know if one of the many, apparently undocumented, probably not reproducible by developers, memory bugs/leaks is fixed.

If you do not try new versions you will not get any fix. It is not possible to rely on internet reports of memory leaks because, it is a certainty they will always be reported for Firefox, and any other popular browser regardless of whatever is fixed.

I participated in the creation of a bug, ....

Thanks for that.

I wish more people were able to take the time to do that sort of thing and so help identify and fix problems.

Sorry to repeat this,
but if you agree problems exist;
they are more likely to be fixed once documented and in the bug tracking system. The first stage of that process is normally to demonstrate a method of reliably reproducing the problem enabling it to be studied and hopefully fixed.

If maybe within this or a new thread anyone can agree on steps to reproduce any issues further bugs may be filed, but please

1. Initially test in safe mode and a clean profile with all plugins disabled, because then the bug is likely to relate to Firefox code, or a specific site. (It is even better to test in Nightly but that is a secondary step).
2. Only if the above fails to reproduce enable a plugin or try not in safe mode
   • if the problem does not manifest in safe mode we should be able to quickly pin down the relevant factor
   • if the problem is a particular plugin, we can notify users, the plugin developers, and Firefox developers.

John99 Given the nature of a memory leak, I understand that the increase in RAM was only a delaying tactic and I have seen the RAM rise to unseen levels. But a 16GB upper limit is a lot more breathing room than 4GB.

I understand that halting FF at 21.0 precludes me from benefitting from any newly-discovered security issues.

I can also assure you that I will resume automatic updates as soon as a solution for this memory leak is incorporated in a RC. The reason I stopped automatic updates was because the memory leak worsened with FF 22.0. As you can see from this response, I am tracking the progress of the bug associated with this issue. When it gets fixed, I will resume automatic updates. (I again draw your attention to the fact that I work professionally as an enterprise architect and am fully cognizant of the issues surrounding software development). Though I appreciate the sentiment in your alerting me to these issues, I was fully aware of the impact of my decision when I shut off automatic updates.

So, I will track the defect I had opened for this issue and respond accordingly when it gets closed. Truly, you don't need to babysit me--I have been a professional software engineer for 16 years and fully understand the issues involved.

Note I have spun off a new thread as most people coming to this thread will just get lost and give up as it is currently 4 pages and 75 replies.

New moderated tracking & cross linking thread on memory problems

• Problem: Memory Leak. Firefox usually on a Mac, OSX; reaches 2-3 GB of RAM -- heap-unclassified -- very quickly (~10 mins)

@John, the reason this is four pages is because people are frustrated at the lack of support and admittance of such a problem. It is also a problem when people have to post nearly a page length of output to get any accreditation at all of their problems.

This would not be a problem if Mozilla stopped playing Ostrich and started playing the hero and solving this once and for all, because this has been happening for way too long.