User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.8.1) Gecko/20061031 Firefox/2.0 Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.8.1) Gecko/20061031 Firefox/2.0 I wish I could be more specific. Several of our Solaris 10/Sparc users including me end up with firefox processes that grow with out bound over several days. On platforms with long running sessions and a lot of ram and vm (like Sunray servers) its not unusual to see a process size over 1GB. I don't see the same on Linux, but we don't administer any Linux machines with long running browser sessions. I'm looking for suggestions on how to track down the leak. Reproducible: Always Steps to Reproduce: 1. 2. 3.

My 2 cents: I've personally experienced Firefox growing above 800 MB several times without ever touching a sparc machine or solaris. Possibly past 1GB (It didn't really surprise me so I don't remember it so well)

You can't judge a memory leak be just looking at the process memory usages. malloc holds a buffer, sometimes it won't release your memory even Firefox frees the pointers. Please refer to http://dbaron.org/log/2006-01#e20060110a and http://dbaron.org/log/2006-01#e20060114a You can also use mdb to detect memory leak on Solaris.

I leave Firefox running for two days, I use prstat to monitor the Firefox process, Two days before, the Size = 319M, the RSS=264M after two days running, the prstat shows: PID SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 10636 1538M 300M run 49 0 1:50:30 3.4% firefox-bin/11 So confirm this bug on Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.8.1.1) Gecko/2007022709 Firefox/2.0.0.1, running on Solaris neveda build_59.

Please read comment #2 before confirming this bug. Please file another bug with enough information.

I can confirm the same phenomenon as in comment 3 on Solaris. I can leave it running overnight and the next morning the size has gotten considerably larger. I did follow the links in comment 2, and did run the leak-gauge. It showed no leaks on exit. As another clue, I find that the X server, Xsun grows along with firefox. So firefox must be pinning down X resources, but from leak-gauge explicitly releasing them on exit. I think the status should be changed from "resolved invalid".

We were puzzled by the same issue (with other programs), too. It came out that this is a feature of solaris (I don't remember it exactly, but if that doesn't suffice for you, I can ask our admin if he still remembers): Although you free() a memory, prstat will still show it. Try it. I think it's about Solaris ressource management/security.

man page of libc free(): After free() is executed, this space is made available for further allo- cation by the application, though not returned to the sys- tem. Memory is returned to the system only upon termination of the application. You should try another malloc library if you don't like that. Perhaps libjemalloc, libmapmalloc, etc.

To find out it's a real memory leak or not, run 'prstat' command in a terminal. If the vaule of 'RSS' field of firefox row keeps increasing, it's a memory leak. If that happens, please give us the detailed steps and urls you accessed.

Still see this? (In reply to Boying Lu from comment #8) > To find out it's a real memory leak or not, run 'prstat' command in a > terminal. > If the vaule of 'RSS' field of firefox row keeps increasing, it's a memory > leak. > > If that happens, please give us the detailed steps and urls you accessed.

I don't know if this is still happening but it is safe to say that it is a wontfix.