Resource Leak in Netscape 7.1 and Mozilla 1.4
Updated 10/30/03

If you are experiencing a resource leak, when running Netscape 7.1, or Mozilla 1.4 then the following information may be beneficial:

As listed in the October 15, 2003, Mozilla 1.5 Release Notes:

* Mozilla should no longer cause GDI problems on Windows.

This is also true of Mozilla 1.4.1, released October 10, 2003. You can download and install Mozilla 1.5 or 1.4.1 from this location: - Releases

End of update

Do read the entire Bug #204374.

Now, to get down to the workaround for your Netscape 7.1 Resource Leak:

Improved about:config Page Makes Editing Hidden Prefs Easier

"Advanced users also may be aware that making changes to these prefs used to involve manually editing your prefs.js or user.js file. However, now you can alter these options directly from within the browser, thanks to the fix for bug 107418.

To take advantage of this new feature, you must be running a recent Netscape, Mozilla, or Phoenix nightly. The feature was introduced in Mozilla 1.3 Beta, included in Netscape 7.1, and included in Firebird .06.

Enter about:config in the Location Bar and a list of preferences will appear. Editing them should be familiar to anyone who has ever hacked the Windows Registry: each pref now has a context menu that allows you to copy its name or value to the Clipboard, modify its setting or reset it back to the factory default value. You can also add unlisted preferences by using the 'New' submenu: select 'String' if the value of the setting you want to add is textual, 'Integer' if it's a number or 'Boolean' if it's either true or false.

Most modifications will take effect immediately but some may require a restart. Note that making changes in about:config updates prefs.js and not user.js. As the user.js file takes precedence, you'll have to manually remove any lines you want to alter from user.js (or delete the file entirely) before making changes in about:config. Finally, remember that you can really screw things up if you're not careful. You have been warned."

As described in Bug Report #204374, this is the additional Preference you should add to about:config:

How To Modify Hidden Preferences Using about:config
This page gives detailed screen shots on how to use the about:config to add or edit new Preferences.

On one of the Netscape Forums, a user asked:
Q.   If I reduce the size of the memory cache, I should reach the limit faster, and, then what? As comment #70 why Memory cache in first place?

A.   Just the reverse. In Netscape 7.1 setting a lower memCache setting slows down the use of resources. It also depends on the amount of RAM that you have installed, as the memory cache is set automatically, based on installed ram. If you set a higher Memory cache setting, you run out of resources more quickly, as you have experienced.

Why memory cache? For the reason stated: "smaller cache gives better performance than either no cache or a large cache." Memory cache draws faster on reload, as it is a portion of memory made of high speed static RAM (SRAM). Disk Cache uses the conventional main memory. By storing this information in the SRAM, the computer avoids slowing down by accessing the slower DRAM, as disk cache draws much slower.

Setting memory cache by adding the script in the user.js file locks out making permanent changes via the UI (user interface) or, in about:config. These settings are profile spefic - not global - as it is if added to a *.js file.

In Netscape 7.02, If you set memory.cache.capacity in the user.js file you can change it via the UI: Edit | Preferences | Advanced | Cache. However, the user.js file will override every time you restart 7.02. The setting will be retained for the session, but not from a re-start. In effect this will preclude any changes you make in about:config from becoming a permanent change, which normally takes effect AND is written to the prefs.js on exit.

If you add what is the "default" setting to the prefs.js file, it is read into memory as default, it will show as such in about:config. It will not, however, show up in the prefs.js file because it is the default setting. No defaults show in prefs.js, if they did, the prefs.js file would be as large as all the *.js files combined.

When you re-start NS, any script you add to the user.js file takes precedence over the prefs.js file, or edits to about:config, therefore nullifying the edit. You are then back to the original user.js setting.

You can make the edit in about:config, and it will take effect. However, it will not be retained past the current session if also entered in the user.js file.

In short: the user.js negates about:config changes, and those changes in about:config or UI will not work beyond the current sessions, if you have conflicting entries in the user.js file.

In this instance, it is recommended that the workaround script should be added to either the about:config, or if the user prefers, to the prefs.js file, rather than the user.js file. Keeping in mind that you should first back up the prefs.js file. When added to the prefs.js, it forces the script to appear in about:config as "user set".

Advanced users only:
You may wish to add the script to the all-ns.js file, If you don't have an all-ns,js, then add it to the all.js file. Again, after first backing up the file. This will not only be a permanent preference but will be permanently retained for both new and existing Profiles, i.e., a global setting.

Syntax for the all-ns.js file to read: pref("browser.cache.memory.capacity", xxxx);

Original cache size is determined by the following entry found in the all.js file:

pref("browser.cache.memory.enable", true);
//pref("browser.cache.memory.capacity", -1); NOTE: calculates cache size based on RAM
// -1 = determine dynamically, 0 = none, n = memory capacity in kilobytes
If you don't like your setting, delete YOUR entry and it will fall back to the above set default.

Holger Metzger confirms this very clearly, by adding his Tweaks to the all-ns.js file, and by adding the A2.js file, in his Compact Releases.

The following comments, taken from two Bug Reports, are a summation of the cause:

Workaround:Bug #204374

---- Additional Comment #69 >From Jim Booth 2003-06-05 08:30 ----

Jo Hermans, Comment #65:

I think you're on to something! I think the fix to Bug 105344 is causing this. Setting browser.cache.memory.capacity to 4096, I was able to open 20 tabs in each of 2 browser windows.

I'll post a comment in Bug 105344. If someone can verify this, I think they should REOPEN Bug 105344.

To review the steps to try this:

If this setting has little or no effect, then increase the value from 1024 KB to 2048 or 4096.

------ Additional Comment #271 From Jacek Piskozub 2003-08-11 11:59 -------

Three days of intensive testing on Windows Me with no side effects (I do not notice the difference caused by the lack of optimalization). This should certainly be part of 1.5beta release (and probably also 1.4.1).

Matti: Asa specificially asked to "try to get some testing across the various windows platforms to see if anyone can shake out any problems" in comment 205893#30 (on a different bug but concerning the patch from this one).

------- Additional Comment #272 From Craig 2003-08-11 22:28 -------

Using Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5b) Gecko/20030810 ,I can finally go back to having 10-15 tabs open without constantly getting "low resources" warnings from Windoze. My GDI's still above 50%, instead of hitting 0% all the time and blowing the O/S up.

Thus far, I've seen no downside either.

------- Additional Comment #273 From Stephen Walker 2003-08-13 21:23 -------

*** Bug 216125 has been marked as a duplicate of this bug. ***

------- Additional Comment #274 From 2003-08-14 13:29 -------

So far in 4 days of pushing it hard with lots of Japanese anime-site windows open, I've had no GDI problems or crashes of any kind on winME using build 2003081004.

------- Additional Comment #275 From Dave Dyer 2003-08-15 17:08 -------

*** Bug 207796 has been marked as a duplicate of this bug. ***

------- Additional Comment #276 From Richard Wheeler 2003-08-15 21:17 -------

After several days of running 2003081104 / Win98se this problem has nor reoccured. Before I was lucky to get half a dozen windows open. The cache workaround had no effect. Now I can run a dozen windows all day. GDI resources remain at 50-60%. I'm a happy camper again.

------- Additional Comment #277 From Ken Cambier 2003-08-17 18:23 -------

This bug seems to be fixed and resource use is lower than ever Build 200308515 at least for me and Win98 SE. Thanks!

From: Gervase Markham
Subject: 2003-08-18 - Summary of staff meeting
Newsgroups: netscape.public.mozilla.seamonkey
Date: 2003-08-21 16:07:43 PST

2003-08-18 - Summary of staff meeting

Present: gerv, myk, seth, asa, chofmann, scc
  (mitchell, blizzard, brendan on vacation.)

*1.5 beta update*

- One bug outstanding (GDI issue)
- After release, about two more weeks on the trunk
- Branch for final with 5-12 bugs left.
- Not scheduled to branch until August 29th.

*1.4 branch (1.4.1)*

- 1.4's focus is the fix for Windows installer crashes, and the GDI leaks.
- Windows installer crashes are fixed on the branch.
- GDI thing fixed, maybe - still looking into this.
- We've also taken other fixes meantime.
End of Bug Report

Personal Comments:
To view the Memory and Disk Cache:   type "about:cache" in the Location Bar.

Although the "Clear Memory Cache" option is not included in Netscape 7.1, clicking on the Clear Cache Tab in the
Edit | Preferences | Advanced | Cache Preferences does clear both Memory Cache and Disk Cache.

The setting of 1024 KB Memory Cache is the preference that works best for me, running Windows 98SE, 384 MB SDRAM rather than 4096 KB.

Although I was able to keep the leak somewhat in control usiing the 2048 memCache setting, frequently clearing Cache, and using minimum tabs, my available resources still dropped to a low 30%.

I decided to try the 1024 setting, which I had also seen recommended. The results are good. I find that I can go back to my Tab Group of 14 tabs, and I don't have to clear the Cache at all. Using the 1024 setting, I find that the resources are released once they have dropped to a very low percentage. When I run the System Resource Meter, I can see that available resources are getting very low, but when I check again, the resources have been released, and I'm back to my normal 68 - 70% available resources.

So if you're experiencing the resource leak, by all means try the 1024 memCache setting, if you haven't already. You can experiment to see what works best on your system. This bug appears to affect Windows 98, ME, Window 2000, and Windows XP.


Back to Bugs:
--- Additional Comment #70 From Kim Scarborough 2003-06-05 08:35 ---

Haven't we kinda known this for a while? Somebody said a long time ago that the workaround was to turn off the memory cache.

Anyway, let's keep in mind that this problem wasn't created by bug 105344, just exacerbated by it. This behavior has been around for awhile. Backing out of 105344 shouldn't be considered a permanent fix, if it comes to that.

Also, it's not just Win9x, contrary to some of the comments here. It's been reported on Win2K and XP.

------ Additional Comment #71 From Jim Booth 2003-06-05 08:48 -------

My point (Comment 69) is that the cache size is getting set too agressively (large) now, and that the OS should be taken into account when setting the size. The time of the fix to Bug 105344 seems to coincide with the major worsening of the symptoms this bug mentions around May 1.

My 384MB Windows ME machine was defaulting to over 18K memory cache size.

It's not necessary to turn the cache off, just set it smaller.

------- Additional Comment #72 From Rob North 2003-06-05 09:14 -------

Regarding Comment #70 & #71:

We've been skirting round this issue for some time: We discovered that turning the cache off improved GDI performance in some areas, but degraded it in others.

What's new is the discovery that a smaller cache gives better performance than either no cache or a large cache.

Regarding what should be done, these would be my suggestions to the developers:

1. As a temporary fix, back out Bug 105344, or intoduce upper bounds to it's algorithm.
2. Investigate either a. not cacheing GDI handles, or b. limit cache entries to number of GDI handles.
3. Investigate resource consumption for multiple tabs.
4. Investigate single pages with high GDI consumption.
5. Investigate any GDI leaks.

That's a lot of work, but my guess is that only 1. & 2. are necessary.

------- Additional Comment #79 From 2003-06-06 08:40 -------
It would seem the the appropriate fix lies somewhere between:

1) post #75 [Mozilla should set memory cache automatically]
2) post #76 [would someone reopen bug 105344 - which was the discussion of what percentage of max RAM should be used for an automatic memory cache sizing algorithm]
3) post #77, 78 [GDI handles shouldn't be in the memory cache because when the cache is big, GDI resources become overloaded in many of the platforms]
4) post #73 [there should be a UI for memory cache size (as in Netscape 4.79), which UI has explanation of why use it, for concerned people standing in the rain (as opposed to sbout:config insertion of browser.cache.memeory.capacity for nerds and tweakers).] The UI would set memory cache value different from an algorithmic default value for people who have memory to burn and want to optimize/force rendering speed by setting memory cache high and disk cache low.
5) post #70 [a rather thorough formulation of all the possible contibutors to the problem]

------- Additional Comment #232 From Jim Dunn 2003-07-28 11:04 --------

I am pretty sure this is a dup of bug 205893. There are two approaches for a fix for this, both are being discussed. I don't know when a solution will be checked in.

But let me assure you, we know the problem, we understand the problem, we are working on the problem... it is just that now we need to make sure the solution is good.

------- Additional Comment #246 From David G King 2003-07-31 20:59 -------

Anything that uses/implements Win32 GDI handles has the potential to exhibit this bug. The main reason Win 9x sees it most is because there are a lot of users, but mainly because it takes far less time for the problem to occur due to Microsoft giving those versions of Windows such a small space for GDI to work in. Win NT, 2K, XP and XP 64bit all suffer from the same problem, it just takes longer to see it due to them having a bigger space for GDI to work in.

------- Additional Comment #248 From David G King 2003-08-01 18:36 -------

One must remember that creating a fix for all the GDI bugs in Mozilla isn't going to be easy. The bugs are in the Browser (Navigator), in Composer, in Mail/Newsgroups and in IRC Chat (hmmm, and probably in Venkman, DOM Inspector and maybe the Javascript console).

------- Additional Comment #266 From Steve 2003-08-10 09:30 -------

This particular problem seems to be solved. I downloaded the 1.5 beta release a couple of days ago and this problem has not recurred.

Mozilla 1.5b Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5b) Gecko/20030808

There are a few other issues with the build but this one seems resolved. Get the August 8th 1.5 release.

------- Additional Comment #267 From S. Burmeister 2003-08-10 13:46 -------

If this bug is solved, we should be sure about what patch solved it in order to patch NS 7.1, that suffers from this bug too.

If you have questions, you can reach either captjlddavis, or me, at the:

SillyDog701 Message Centre, Netscape & Mozilla Forum
WindowsBBS Netscape Navigator Forum


Back to Top

Return to Netscape Solutions