Reproducible: Always Steps to Reproduce: 1. Go to http://www.t45ol.com/play_flash.php?ID=789 2. Click "GAME START" Expected Results: The Mem Usage and VM Size of the mozilla.exe process as reported by the Windows Task Manager remains at about the same level. Actual Results: The Mem Usage and VM Size increase at the rate of about 1.5 MB per minute. Most of the additional memory used does not go away when the window the Flash game was in is closed. This was initially reported in the MozillaZine Firefox Support forum as a problem with Firefox 1.0.2. I can reproduce the memory leak with Mozilla trunk build 2005040406 on Windows XP SP2. IE and Opera 8 beta 3 do not exhibit the memory leak on the same page. about:plugins reports "Shockwave Flash 7.0 r19".

Isn't this a memory leak in Flash (or the game itself) ?

I can also reproduce this memory leak with Flash 7.0 r19, Firefox 1.0.2 and a Mozilla 1.7.7 nightly, but not with IE6.

(In reply to comment #1) > Isn't this a memory leak in Flash (or the game itself) ? That's what I thought at first, too. But the leak doesn't occur in other browsers, just Mozilla.

Are the other browsers using the same Flash plugin? IE certainly doesn't; what other browsers did you test?

As I said above, Opera 8 beta 3. I just retested with Mozilla trunk build 2005051006, and I can't reproduce the leak. Maybe this is one dbaron plugged recently?

I need to learn to read... Yeah, dbaron's changes could have made things better here...

This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/

I can reproduce with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20050927 Firefox/1.4. I'm using Shockwave Flash 8.0 r22. I cannot reproduce on the same system using Opera 8.5 with the same Flash plugin. Worse, staying on that page causes a crash in about 30 minutes. Talkback IDs: 9802983 and 9810175. I can try to find a (recent) regression range if you like.

If you could, that would be wonderful!

Testing with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050510 Firefox/1.0+ and Mozilla trunk build 2005051006, both with Shockwave Flash 8.0 r22, both show a memory leak but no crash. I tried going back to Flash 7.0 to retest, but can't get Flash 7.0 to install or Flash 8.0 to uninstall. Maybe I'll check to see if the leak or crash happens with Firefox 1.0.7 and Mozilla 1.7.12...

After testing and re-testing, I find that sometimes I can reproduce the bug in a given build, and sometimes I can't. I was able to reproduce it once in Firefox 1.0.7, but now I cannot reproduce it in Firefox 1.0.7, Firefox 1.8 branch build 20051016, SeaMonkey 1.8 branch build 2005101611, nor Firefox trunk build 20051016. It's possible the bug has always existed, so I'm removing the regression keyword.

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

t still happens on Firefox 1.5 ( Mozilla/ 5.0 , en-US;rv:1.8 , Gecko/20051111 ). Im using flash 8 r22 , still the same sp2 . I noticed that now it uses only 78 mb of ram , but still its an abnomilal high rate ; from 30-40 mb initialy , it goes up to 78 mb ! Another thing i noticed , while i deactivated explorer exe from task man . ; the procces started to go way down with the memory request ; it needed only 10 mb !

Using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 (Ubuntu 5.10), I am confirming this. 122MB to 135MB (total memory) in 5 minutes. my memory usage in detail was: -before opening game site: at 122MB (already leaked from 100MB in 4 hours mild usage as to https://bugzilla.mozilla.org/show_bug.cgi?id=320915 ) -open game site and play 5 minutes: goes up to 145MB -close game site: goes down to 135MB PS. memory leak is small probably due to browser.sessionhistory.max_total_viewers = 0 was set up prior to trial as provided by https://bugzilla.mozilla.org/show_bug.cgi?id=320915 and https://bugzilla.mozilla.org/show_bug.cgi?id=319262 .

If you're seeing just 10-20 MB additional memory usage, you're not seeing the memory leak described by this bug report. When the memory leak occurs, memory keeps climbing without limit until the browser doesn't work or crashes. You may need to wait a few hours, possibly with the game in the active tab, and possibly even in the active window (i.e. you cannot do anything else with your computer while the memory leaks). If you don't see more than 100 MB of extra memory consumed overnight, I don't think you're seeing this bug.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060912 SeaMonkey/1.5a I see huge leaks at flash sites, for instance http://www.aftenposten.no/ Loosing around 3MB per minute. If the browser is left on that page for some hours, the leak jams all physical RAM (1G) as well as all available virtual memory. Which of course causes the system to come to a grinding halt. In this state it even takes 5-10 minutes to kill or exit Seamonkey. Raising severity - this is severe.

(In reply to comment #16) > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060912 > SeaMonkey/1.5a > > I see huge leaks at flash sites, for instance http://www.aftenposten.no/ > Loosing around 3MB per minute. There are many reasons why you would see memory increase at a site that has Flash content. One is that the Flash content itself has a memory leak; this would be fixed by changing the content on the site. Another is that the Flash plug-in leaks; this would be fixed by Adobe fixing the plug-in. Yet another is that there's a leak in SeaMonkey; this is the only one that could be fixed by Mozilla developers. You should report the problem you see in another bug report, and we can determine which reason is causing the memory usage you see and alert the party that can fix the bug. You should mention the version of the Flash player you're using and whether you see the leak in other browsers. I'm not seeing the problem with the site you report using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20060919 SeaMonkey/1.1b.

It's Flash version 9,0,16,0 The same version for MSIE does not leak, indicating it isn't a problem with the flash on the site as such. For fun, I tested it the latest release 1.0.5 also, and the leak was hardly noticable there. But in trunk builds 2006052109 and 1.9a1 20060912, it leaks like a sieve. Smells like a Mozilla problem to me. For now I'll just uninstall flash and try if i can get a newer trunk build from mozilla.org later (download speed is bad right now, will take hours) - perhaps it's finally fixed?

> The same version for MSIE That's a completely different program. But yes, leaking on trunk but not branch is a more important indicator. Please file a separate bug? And any info on when it regressed would be nice -- 1.0.5 is about a year old in Gecko terms. :(

Filed bug 354087. BZ: Sorry, I don't know when this started.

noting this originated with 1.7 Boris Zbarsky in comment #6: > ... dbaron's changes could have made things better here... bz, what changes would that have been?

Um... He made a ton of changes to GC in the 1.8.1/1.9 timeframe. Everything involving nsIDOMGCParticipant, etc. Multiple bugs, lots of code.

The recent increase in leaks on trunk is bug 354087 which is marked as a blocker. Not blocking on this one since it's too old and not clear what's going on.

sicking in comment #23 > not clear what's going on. true. an attempt to summarize ... wmode transparent is in the page, so this may partially be bug 341380 which goes go back as far as 2004. Have to wait for adobe to provide that fix before we know the final disposition of this bug. But going back further on this bug and contrasting with the newer bug 354087 (which is gecko 1.9) ... the original report here is flash v7 + gecko 1.7/ff 1.0, gone in comment 5 -- so the bug really should have been closed after comment 5/6. then, we have comment 8 against flash v8 and gecko 1.8 2005-09-27, clarified in comment 10 which puts the issue starting prior to 2005-05-10. *2005-05-10 makes this bug the oldest report against gecko 1.8/ff 1.5*. There is also bug 309890. it would help of course if flash+FF hadn't been so buggy over the years. some issues, like bug 341380, persist across flash versions, some have gone away and maybe returned - perhaps this is one example. anyway, we know the problem with this URL with 1.8 goes back to at least 2005-05-10. here's one of the searches I used. https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Core&product=Firefox&version=1.4+Branch&version=1.5.0.x+Branch&version=1.8+Branch&version=Trunk&version=unspecified&long_desc_type=allwordssubstr&long_desc=flash&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_severity=critical&bug_severity=major&bug_severity=normal&op_sys=All&op_sys=Windows+95&op_sys=Windows+98&op_sys=Windows+ME&op_sys=Windows+NT&op_sys=Windows+2000&op_sys=Windows+XP&op_sys=Windows+Server+2003&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2004-08-01&chfieldto=2005-05-01&chfield=%5BBug+creation%5D&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&known_name=flash-opaque&query_based_on=flash-opaque&field0-0-0=short_desc&type0-0-0=nowordssubstr&value0-0-0=cache+crash+exten+spell&field1-0-0=short_desc&type1-0-0=anywordssubstr&value1-0-0=memory+flash+cpu+slow&field1-0-1=keywords&type1-0-1=anywordssubstr&value1-0-1=mlk+hang+perf&field2-0-0=longdesc&type2-0-0=substring&value2-0-0=rv%3A1.8&field2-0-1=noop&type2-0-1=substring&value2-0-1=opaque&field2-1-0=noop&type2-1-0=noop&value2-1-0=

Could be related to [Bug 273364 – Serious memory leak after running several days or weeks, especially with Flash animations] too !?

(In reply to comment #25) > Could be related to > [Bug 273364 – Serious memory leak after running several days or weeks, > especially with Flash animations] too !? reporter doesn't say he tested windows in Bug 273364 comment 0 which reads "This seems to be a Solaris specific issue cause I can't see it on MacOS or OS/2.", so it is possible these are the same. but I think adobe treats most flash problems as being platform specific, so I doubt it would be helpful to dupe a flash bug unless it's same platform+symptoms or the problem is proven to be a mozilla problem and not an adobe problem. also not tested was linux, so 273364 might be one of the zillion linux+flash bugs. Bug 139751 comment 14 documents a few

Please check with a trunk build dated 2007-06-08 or later. WFM - memory usage nominal with patch from core bug 342810 checked in on 2007-06-07, though I confess I don't have a clue how to play the zoo game. The patch is contained in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/2007060809 SeaMonkey/2.0a1pre Used Shockwave Flash 8.0 r22 - the suiterunner install picked up an old version of flash from C:\WINNT\system32\Macromed\Flash\NPSWF32.dll tested with seamonkey because FF trunk build process is broke ATM. http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/ I did not do a comparison to a prior build to see it was still a problem just prior to 2007-06-08

It turns out http://www.t45ol.com/play_flash.php?ID=789 is really not a good URL to test because it has a mixed set of problems. I've split it into two testcases: * flash adverts only http://www.t45ol.com/recherche.php * game only http://sd1224.sivit.org/random_9032/files/789.swf measured at end of game screen which reads "retry" and "submit score" game ads without TM fix [1] A. 300k/min C. 1.0MB/min with TM fix [2] B. dead flat D. 500k/min, and 100k/min after 4 mintues memory does not go up if window not visible [1]http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2007-06-07-09-trunk/ [2]http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2007-06-08-09-trunk/ Comparing A. and B., problem is gone - initial checkin of bug 342810 (threadmanager) fixes the game (at least for that screen of the flash). Comparing C. and D., initial checkin of bug 342810 partially fixes the adverts. So what remains is to be tested is: 1) the final checkin of bug 342810 and 2) the new version of flash mentioned in bug 341380

(In reply to comment #28) > It turns out http://www.t45ol.com/play_flash.php?ID=789 is really not a good URL >... > game ads > without TM fix [1] A. 300k/min C. 1.0MB/min > with TM fix [2] B. dead flat D. 500k/min, and 100k/min after 4 mintues > memory does not go up if window not > visible TM=ThreadManager

I'm not seeing any memory leak on Zoo Keeper now with a recent Firefox trunk build, but then again, the problem has mysteriously gone away and reappeared in the past. Anyway, if no one can reproduce the problem, it should be marked WFM.

sounds good. closing FIXED - fixed by bug 342810 as documented in comment 28

But it couldn't have been the patch from that bug that fixed this problem. This problem predates that problem by over one year. Resolving WFM.

Your logic is incomplete. If you can demonstrate that it's fixed (works) prior to 2007-06-08-09-trunk/ or fails on or after 2007-06-08-09-trunk/ then my testing was not sufficient and bug 342810 didn't affect your problem and it's WORKSFORME. Else if you can't, it doesn't matter that your problem predates the initial report of bug 342810 by a year - its still FIXED.

The report of this bug doesn't just predate the *initial report* of bug 342810 by a year. The report of this bug predates when that bug was introduced into the codebase by a year. That means *the two bugs are different*. Of course you were seeing the Zoo Keeper flash game leak memory, and that leak was fixed by the checkin to bug 342810. That bug caused all sites with Flash to leak, including specifically the Zoo Keeper Flash game. When that bug was fixed, it caused all sites with Flash to stop leaking memory due to that bug, including the one in this bug report. But on top of that generic Flash memory leak problem, there was *another problem*, specific to the Zoo Keeper game, that now seems fixed. I have no idea what patch fixed it, so the proper resolution is WFM.