602190 - [OpenGL] Memory leak with flash content

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Zio_Fede]

User-Agent:       Mozilla/5.0 (X11; Linux i686; rv:2.0b7pre) Gecko/20101006 Firefox/4.0b7pre
Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b7pre) Gecko/20101006 Firefox/4.0b7pre

Firefox occupies the entire memory

Reproducible: Always

Steps to Reproduce:
1.Go to http://www.divineproject.altervista.org/ with layers.accelerate-all->true
2.Wait till the site is loaded

Actual Results:  
Firefox will eat up the whole RAM and swap

Expected Results:  
Firefox should not occupy the whole ram suddenly

I'll try to find the regression range ASAP.

Comment 1

[Zio_Fede]

I don't think it blocks, opengl layer acceleration according to mozilla wiki, is not going to be activated by default in firefox 4...
anyway it seems another regression caused by https://bugzilla.mozilla.org/show_bug.cgi?id=598112

Comment 2

[Boris Zbarsky [:bzbarsky]]

> is not going to be activated by default in firefox 4...

On Linux, perhaps.  Is this issue linux-specific, or does it also hit GL layers on Mac?

Comment 3

[Zio_Fede]

Yes, I was talking about linux, and I dont't have a Mac to test this

Comment 4

[Oleg Romashin (:romaxa)]

> https://bugzilla.mozilla.org/show_bug.cgi?id=598112

598112 - this is just enabling plugins rendering with layers, and plugin-layers rendering not leaking with non-accelerated environment.

Comment 5

[Mike]

On Linux with layers.accelerate-all=true, FF consumes about 5 times more RSS memory (~150 Mb vs ~800 Mb)
PS. without flash

Comment 6

[Hilinus Fenfort]

Confirmed here on Linux x86.

User Agent:
Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101014 Firefox/4.0b8pre

Comment 7

[Zio_Fede]

Layer acceleration was usable before this bug...

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Is this a leak or just excessive memory usage? In other words, if you close the window containing the Flash object, does everything return to normal?

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This actually seems like something the mobile people will want fixed, either way.

Comment 10

[Mike]

(In reply to comment #8)
> Is this a leak or just excessive memory usage?
In my case its the second. FF uses >1gig versus ~200Mb without OpenGL (desktop)

Comment 11

[Zio_Fede]

(In reply to comment #8)
> Is this a leak or just excessive memory usage? In other words, if you close the
> window containing the Flash object, does everything return to normal?

No, closing the tab just prevented firefox to occupy the whole swap, it does not free the memory.

Comment 12

[Joe Drew (not getting mail)]

Someone needs to confirm this before I'll consider blocking.

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We've got three independent reports here.

Comment 14

[Joe Drew (not getting mail)]

(In reply to comment #11)
> No, closing the tab just prevented firefox to occupy the whole swap, it does
> not free the memory.

Just closing a tab might not be enough - what if you close the tab and then kill plugin-container? That should cause any resources used by plugins to be freed up.

Comment 15

[Zio_Fede]

(In reply to comment #14)
> (In reply to comment #11)
> > No, closing the tab just prevented firefox to occupy the whole swap, it does
> > not free the memory.
> 
> Just closing a tab might not be enough - what if you close the tab and then
> kill plugin-container? That should cause any resources used by plugins to be
> freed up.

Negative, by killing plugin-container I only managed to make firefox crash the first time. So I tried it again and after successfully killing the container firefox didn't free the ram.I've just forgotten to say that is the firefox process to occupy the ram, not the plugin-container one.

Comment 16

[Joe Drew (not getting mail)]

This doesn't block gecko 2.0 since it's linux + OpenGL only, but I'm nominating it for Fennec to see if it affects them. If it does, it should block!

Comment 17

[Doug Turner (:dougt)]

karlt, is this something you can look into?

Comment 18

[Karl Tomlinson (:karlt)]

Yes, I can investigate.
I'm not planning to look specifically at this in the next couple of weeks, though I am learning more about the code enabled by bug 598112 while working on other bugs.

Comment 19

[Erdem U. Altinyurt]

That site don't load on my setup, x86_64 OpenSUSE 11.3 fglrx 10.11 HD6850 adobe linux x64 10.1  using nighly minefield 4.0b8pre

Loading site generate artifacts on flash animations too.
Here is the screenshot
http://img804.imageshack.us/img804/9614/screenshotib.png

Comment 20

[Zio_Fede]

(In reply to comment #19)
> That site don't load on my setup, x86_64 OpenSUSE 11.3 fglrx 10.11 HD6850 adobe
> linux x64 10.1  using nighly minefield 4.0b8pre
> 
> Loading site generate artifacts on flash animations too.
> Here is the screenshot
> http://img804.imageshack.us/img804/9614/screenshotib.png

Could be this bug if you see the artifacts even with layers.accelerate-all set to false https://bugzilla.mozilla.org/show_bug.cgi?id=603397.

Comment 21

[Erdem U. Altinyurt]

Nop I use 64bit flash and don't have ndiswrapper plugin. Artifacts seen on just accelerate-all = true state. No problem on accelerate-all = false.

Comment 22

[Zio_Fede]

(In reply to comment #21)
> Nop I use 64bit flash and don't have ndiswrapper plugin. Artifacts seen on just
> accelerate-all = true state. No problem on accelerate-all = false.

Uh, anyway it is not a stable release of flash...you should try with the 10.2 "square" release and see if it happens, I'm not seeing any artifacts with the 32 bit release.

Comment 23

[Zio_Fede]

I can't reproduce anymore this bug on the URL of this bug, anyway Firefox barely responds to inputs, like it does with layer acceleration enabled on windows xp...I'll try to see if some other flash animations trigger this bug.

Comment 24

[Zio_Fede]

Ok, marking as wfm...