246713 - Flash in iframe leaks memory and CPU usage creeps up

Status: RESOLVED INVALID

(Core Graveyard :: Plug-ins, defect)

Description

[Ian Neal]

Using BuildID 2004060809 on WinXP SP1
1. Log into above site
2. Start taskmanager and watch memory/CPU for mozilla

Expected Results
memory/CPU stays fairly constant over time

Actual Results
memory/CPU rises up and up over a period of 10-15 mins

Comment 1

[Ian Neal]

Attachment: Reduced test case

Zip contains test case (3 html files and swf file)

Comment 2

[Martijn Wargers (dead)]

I can see the memory rising over time, with the attached testcase.
However, I think I see the same thing happening in IE6, with the testcase.
So this would then be more a flash issue than a mozilla bug.

Comment 3

[mhonline]

have a look at this

http://bugzilla.mozilla.org/show_bug.cgi?id=247222

I guess there is a problem in task-handling of Mozilla from vers.1.7 onwards

Martin

Comment 4

[Worcester12345]

mlk keyword?

Comment 5

[José Jeria]

Just visiting any site that uses flash makes the memory usage go up very fast,
another exmample is http://www.gamespot.com

Comment 6

[Steve Chapel]

Dupe of bug 334322?

Comment 7

[Ian Neal]

Bug 334322 does not involve iframes but the cause may be the same - the plugin -> adding dependency

Comment 8

[Steve Chapel]

The reduced testcase did make my memory use go up about 5 MB in 15 minutes, using Flash Player 9 beta 3 and a recent SeaMonkey 1.0.x nightly on Windows XP SP2. The far worse problem is that after that time, CPU usage went to 50% (which is essentially 100% CPU for one thread on the hyperthreaded CPU) and Windows said that SeaMonkey was not responding. After about a minute, I managed to close the tab that the testcase was running in, and memory use and CPU use went back down. I tried the testcase in Opera 9 beta 1, and got essentially the same results. It looks like a bug in Flash Player 9 beta 3, so CCing a Macromedia employee on this bug.

Comment 9

[Michelle Sintov]

Thanks for the heads up, we (the Flash Player team) will investigate.

Is it correct that in the reduced test case zip file I should just open AAMSZ468X60.html, or do I also need to do something with 3990-21328-3682-0.html?

Comment 10

[Steve Chapel]

(In reply to comment #9)
> Is it correct that in the reduced test case zip file I should just open
> AAMSZ468X60.html, or do I also need to do something with
> 3990-21328-3682-0.html?

I opened just AAMSZ468x60.html. It contains an iframe which contains 3990-21328-3682-0.html. Within minutes of opening the file, the Flash ad slows down and the CPU is maxed out.

Comment 11

[Ian Neal]

AAMSZ468X60.html is the correct file to open, the other one is the one sourced from the <iframe>.

Comment 12

[Michelle Sintov]

Thanks for the information.

Actually, I can reproduce this problem when just the SWF file itself is opened in the browser. This does appear to be a Flash Player issue.

Comment 13

[Michelle Sintov]

Unfortunately, the issue is in the SWF itself. This web content is authored to hold onto the objects that it creates, so the Flash Player cannot release them. Specifically, it creates an ActionScript Interval timer every frame or so, which is tied to an ActionScript function, so the Flash Player itself can't garbage collect it.

Comment 14

[Steve Chapel]

Resolving invalid per comment 13.

Comment 15

[Wayne Mery (:wsmwk)]

Michelle in comment #13:
> Unfortunately, the issue is in the SWF itself. This web content is authored to
> hold onto the objects that it creates, so the Flash Player cannot release them.
> Specifically, it creates an ActionScript Interval timer every frame or so,
> which is tied to an ActionScript function, so the Flash Player itself can't
> garbage collect it.

Michelle, how can one determine what you mention above about the SWF file?

And, given the above, is it correct that this bug has no connection the blocking bug, where in bug 334322 Comment #24 you state "This bug is now fixed in Flash Player 9 beta 3"?