Memory leak while playing Zoo Keeper Flash game




13 years ago
10 years ago


(Reporter: Steve Chapel, Unassigned)



1.7 Branch
Windows XP
Dependency tree / graph
Bug Flags:
blocking1.8b5 -
blocking1.9 -
wanted1.9 +

Firefox Tracking Flags

(Not tracked)





13 years ago
Reproducible: Always

Steps to Reproduce:
1. Go to
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".

Comment 1

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

Comment 2

13 years ago
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.

Comment 3

13 years ago
(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?

Comment 5

13 years ago
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
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:

Comment 8

12 years ago
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.
Ever confirmed: true
Flags: blocking1.8b5?
Keywords: crash, regression
If you could, that would be wonderful!

Comment 10

12 years ago
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...


12 years ago
Flags: blocking1.8b5? → blocking1.8b5-

Comment 11

12 years ago
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.
Keywords: regression

Comment 12

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

Comment 13

12 years ago
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 ! 

Comment 14

12 years ago
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 )
-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 and .

Comment 15

12 years ago
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.

Comment 16

11 years ago
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 
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.

Comment 17

11 years ago
(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 
> 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.

Comment 18

11 years ago
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 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.  :(

Comment 20

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


11 years ago

Comment 21

11 years ago
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?

Version: Trunk → 1.7 Branch
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.
Flags: blocking1.9?
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.
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]

Comment 24

11 years ago
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.
Depends on: 267599


11 years ago
Depends on: 341380
No longer depends on: 267599
Blocks: 373759
Could be related to
[Bug 273364 – Serious memory leak after running several days or weeks, especially with Flash animations]
too !?

Comment 26

11 years ago
(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

Comment 27

11 years ago
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.
I did not do a comparison to a prior build to see it was still a problem just prior to 2007-06-08 

Comment 28

11 years ago
It turns out 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 
*          game only
       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


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

Comment 29

11 years ago
(In reply to comment #28)
> It turns out 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


Comment 30

11 years ago
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.

Comment 31

11 years ago
sounds good. closing FIXED - fixed by bug 342810 as documented in comment 28
Last Resolved: 11 years ago
Resolution: --- → FIXED

Comment 32

11 years ago
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.

Comment 33

11 years ago
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.

Comment 34

11 years ago
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.
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
You need to log in before you can comment on or make changes to this bug.