User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 Load the page http://swarmcast.net/install/ and without clicking on anything, let it run for a while. It will run in a loop attempting to load images from localhost until it succeeds. This process does not cause a memory leak in IE, but causes a very aggressive leak in Mozilla. We can do a workaround where we make the image pings less aggressive, but we wanted to leave it this way for you so you could see just how bad this leak can be. Reproducible: Always Steps to Reproduce: 1. Load http://swarmcast.net/install/ 2. Don't click on anything, let it run for a while 3. Watch the memory usage climb Actual Results: Memory usage increases without bounds. Expected Results: Memory usage should remain constant. IE exhibits no such leak.

startPinging() is the method that starts iterating the image ping process that causes the leak.

Any advice on workarounds would also be greatly appreciated.

Firefox 1.5 RC3 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5) Issue seems to be solved in this version.

We're still seeing memory leak at a rate of about 4KB/s on 1.5RC3. This may be slower than before, but certainly hasn't resolved the problem.

I do see the leak, but a fairly slow one. Letting the browser sit on the swarmcast.net/install/ page memory use grew from 88Mb to 96Mb in about an hour. Closing that browser window got me less than 1Mb back. I wouldn't call this "aggressive" anymore, but it is a leak.

Need to try this on the trunk, the fix for bug 241518 might have addressed this.

Multiple open browsers RAPIDLY accellerate this problem. My 720mb free memory (after XP is loaded, of course), goes down to approximately 11mb within 20 minutes, after which time Firefox crashes and all browser sessions are closed.

so erm. firefox only uses a single process for all of its windows, so when it crashes, all of its windows *will* go away when you let the app die (if you attach a debugger instead, they'll stick around until the debugger lets the app die).

(In reply to comment #0) > Steps to Reproduce: > 1. Load http://swarmcast.net/install/ > 2. Don't click on anything, let it run for a while > 3. Watch the memory usage climb > > Actual Results: > Memory usage increases without bounds. Justin Chapweske, what will happen if next step is added? 4. While watching memory usage is climing, open a new tab. If virtual storage(memory) size decreases when step 4, it may be same as or similar to Bug 319980. (Sorry but I didn't read the script deeply yet.)

(In reply to comment #6) > Need to try this on the trunk, the fix for bug 241518 might have addressed > this. > Still present on trunk-linux from 6-30. dbaron's leak monitor doesn't appear to reveal anything either. :-(

--> blocking, TM is beta2 Shaver says that this is definitely something we'll want to look into. CC'ing the usual JS suspects, and Joey Minta who said he'd apply dbaron's mlk tool to this thing and get some idea of how badly we're doing here.

(In reply to comment #11) > ... and Joey Minta who said he'd apply dbaron's mlk tool to > this thing and get some idea of how badly we're doing here. > See comment #10, although I'll continue to poke around and see if I can minimize this a bit more.

Joey, have you tried testing this with Leak Gauge to see if it reports anything useful?

(In reply to comment #13) > Joey, have you tried testing this with Leak Gauge to see if it reports anything > useful? See comment 12, which will refer you to comment 10!

This is a core bug, most likely, moving over where it'll get retriaged.

I don't think this blocks now, but letting the Gecko side decide.

Per drivers: Not going to block this late for 1.8.1, nominating for 1.9.a1

To debug this kind of problem, you should probably use diffbloatdump. In more detail: 1. do a build with --enable-trace-malloc 2. follow the list of steps in bug 81446 comment 14, except: + replace steps 3 and 4 with loading the leaky page + replace step 6 with waiting for it to leak + replace the URL in step 5 with http://dbaron.org/mozilla/tests/trace-malloc 3. run diffbloatdump.pl on the logs generated by steps 5 and 7 as described in bug 81446 comment 14

I also have a simple Javascript app used as a slideshow. The app does not really exit the page, so there does not seem to be a trigger to force a flush of memory in Firefox. Similar to the report above, my app works fine in IE 6 and 7, which seems to flush memory every 5 - 10 images. I am using Firefox 2.0.0.9. I am uploading the 3 small test files that demonstrate the issue (see MemoryLeadDueToImageLoad.zip above). Put all 3 files in the same directory. You will need to provide a number of image files named Image001.jpg, Image002.jpg, etc. (or you can modify the list in inc_bill.html). Then run pix.html, and either click on Next in the header or use the Right Arrow key. Observe memory use in Task Manager et al. It will increase with each image loaded.

See my posting for details, also contained in the readme.txt file within.

I tried the original URL with Firefox 3 beta 1 on Windows XP, and memory use did not rise at all after 15 minutes. I also tried the attached testcase with 601 JPEG images. I continually held the right arrow key down for five minutes, and memory usage did not go up, even after going through all 601 images several times. Does anyone have a testcase that causes memory usage to rise dramatically in Firefox 3 due to images loaded by JavaScript, but does not lock up Firefox 3 completely?