354087 - severe memory leak with flash plugin

Status: VERIFIED DUPLICATE of bug 342810

(Core Graveyard :: Plug-ins, defect)

Description

[R.K.Aa.]

There's a severe memory leak with the new flash plugin, possibly also older ones.

I haven't used flash much untill a month ago. After which I kept noticing that the laptop suddenly started to come to a grinding halt, if I left Mozilla running unattended for some hours.

System has 1GB of physical RAM installed. The slowness was caused by SeaMonkey repeatedly using around 1.5GB of RAM.

Testing a little and found this:

Flash version 9,0,16,0 
Gecko/20060924 trunk, SeaMonkey/1.5a
-After startup to blank page: 22.5MB used
Loading http://www.aftenposten.no: RAM usage up to 50MB 
RAM usage now steadily climbed, over 95MB in use after 10 minutes idle there.

The leak does not occur if flash is not installed.
----

Same test, same flash, but with old SeaMonkey/1.0.5 release, Gecko/20060910:

- After startup to blank page: 21.2MB used
- After loading http://www.aftenposten.no: 48.4 MB used (approx)
- After 4 minutes idle:  49,6MB
Then some server side push reloaded the page and it bumped to 55.4MB
- After 6 more idle minutes: RAM usage ended at 55.6MB

A 4.5 MB per minute leak is pretty bad..

Comment 1

[Boris Zbarsky [:bzbarsky]]

Martijn, jmott, can you reproduce this?

Comment 2

[Ria Klaassen (not reading all bugmail)]

This appears to have regressed between 1.9a1_2006051010 and 1.9a1_2006051022.
Unfortunately I had no time to double-check this.

Comment 3

[Martijn Wargers (dead)]

Then I think this is a regression from the threadmanager patch, bug .
Similar to bug 341430, maybe.

Comment 4

[R.K.Aa.]

I see the other potentially related bugs mention problem with closing down after exit of Mozilla:
I kinda see that too, but it's simply an extreme slowness. RAM usage slowly counts down (actually first up, then down) while the disk is continously grinding, swapping memory to kingdom come. Can take around 10 minutes to exit when it's really jammed. I haven't seen anything like this since i used a VAX.

Comment 5

[Ryuichi KUBUKI]

(In reply to comment #4)
> I see the other potentially related bugs mention problem with closing down
> after exit of Mozilla:
> I kinda see that too, but it's simply an extreme slowness. RAM usage slowly
> counts down (actually first up, then down) while the disk is continously
> grinding, swapping memory to kingdom come. Can take around 10 minutes to exit
> when it's really jammed. I haven't seen anything like this since i used a VAX.

I see that too on

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060928 Minefield/3.0a1 ID:2006092821 [cairo]

that consumed 575MB RAM, but not sure if it has anything with Flash.

Comment 6

[Wayne Mery (:wsmwk)]

what version of flash player?

shows version http://www.macromedia.com/software/flash/about/

Comment 7

[Ryuichi KUBUKI]

(In reply to comment #6)
> what version of flash player?
> 
> shows version http://www.macromedia.com/software/flash/about/
> 

9,0,16,0

Right now it takes 220MB
Opening http://www.aftenposten.no/ gave me 20MB rise and killing it gave back 10MB

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061012 Minefield/3.0a1 ID:2006101203 [cairo]

Comment 8

[Wayne Mery (:wsmwk)]

beta update for flash player http://labs.adobe.com/technologies/flashplayer9/releasenotes.html
- haven't tested yet to see if it's any better.

Comment 9

[Steve Chapel]

Dupe of bug 342810?

Comment 10

[Boris Zbarsky [:bzbarsky]]

Maybe, but we won't know till one of them gets fixed.  Then we test the other one.

Comment 11

[Olivier Vit (just a reporter)]

Flash Player update has just been released today 9 r28
http://www.adobe.com/shockwave/download/download.cgi?P1_Prod_Version=ShockwaveFlash

Comment 12

[Olivier Vit (just a reporter)]

Running latest Flash player 9r28 with Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.9a1) Gecko/20061020 SeaMonkey/1.5a

With more than *2* tabs with multiple Flash animated ads on each pages, now CPU usage is 100% but memory usage is pretty much stable (just because the CPU can't handle any more ?)
http://www.boursorama.com/
http://www.meteofrance.com/FR/mameteo/prevVille.jsp?LIEUID=FR93048

Sempron 2500+ with 1GBytes of RAM

Comment 13

[Wayne Mery (:wsmwk)]

flash 9 r28 reduced the rate of memory use by 25% in my test, from 650k/min using r22 to 500k/min using r28.

http://www.hostchart.com/button.swf

Comment 14

[Jim Mathies [:jimm]]

Hey all - Boris checked in a patch for Bug 342810 this morning, and I've been testing the pages listed here. 

Flash Version: 9,0,45,0

http://www.aftenposten.no - I see no appreciable memory climb on this site. I let it sit for about 20 minutes, the memory climbs up slowly while the Flash content loads and caches, but after a while it levels out at about 42MB and holds constant. The cpu usage hovers around 2-6%. (Considering the number of animations on that page, this seems reasonable.)

http://www.boursorama.com/ - Similar situation, after a minute or so memory usage levels at 28MB. CPU usage is between 3-8%.

http://www.hostchart.com/button.swf - Memory is flat line at 28MB, CPU is flat line at 0%.

I also checked www.aftenposten.no by opening it, letting it sit, and then closing the tab. Results - 25MB -> site loads -> 44MB -> close Tab -> 27MB. I think that's pretty respectable. 2.0.0.4 is acting similarly.

Looks like this was a dupe of 342810. I'll go ahead and mark it as such.

Comment 15

[R.K.Aa.]

Verifying dup: No more leak in Gecko/2007060802 SeaMonkey/2.0a1pre
And it was still present in the previous build; 2007060714, which just missed the patch. Both tested with Shockwave Flash 9.0 r45

Thank You, BZ! Grrreat to finally play with nightlies again :)

Comment 16

[R.K.Aa.]

.. and thank you Jim Mathies! - and the rest who collaborated in the other bug. Didn't read it properly before now.