398537 - aPNG images in css cursor rule leak a lot of memory

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Olivier]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.6) Gecko/20070801 (Debian-1.8.1.6-1) Epiphany/2.14
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9a9pre) Gecko/2007100404 Minefield/3.0a9pre

aPNG images used in a css cursor rule trigger a condition where memory is consumed until exhausted. 

Reproducible: Always

Steps to Reproduce:
1. monitor memory consumed by the firefox process. Load the testcase
2. open the menu in the testcase and hover quickly on elements
3. see memory consumption going up
Actual Results:  
Leak

Expected Results:  
Not leak :-)

I tried to simplified the testcase, but am still confused what exactly the problem is (some bad interaction between css and aPNG).
Note that:
- this aPNG file, when displayed in the browser, doesn't (appears to) leak memory, and displays fine (either as fixed in ff2, or animated in ff3)
- the same testcase, if using a regular png, doesn't leak
- a regular PNG image is correctly displayed as a css cursor, while aPNG is not (this may be another bug/RFE)
- this affects ff2 as well

Comment 1

[Olivier]

Just thought I would mention this (of course?) affects other Gecko browsers as well.

Comment 2

[Mats Palmgren (inactive)]

GTK2 nsWindow::SetCursor leaks 'pixbuf' when the image is too big:
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/widget/src/gtk2/nsWindow.cpp&rev=1.229&root=/cvsroot&mark=1031,1041,1042#988
Looks like there are a few other leak paths in this method as well.

It's a regression from bug 361298, so it also occurs on branches and the
leak is pretty bad so we should probably fix this on branches as well.
Patch coming up...

Comment 3

[Mats Palmgren (inactive)]

Attachment: Patch rev. 1 (trunk and 1.8)

Fixes leak and OOM problems. This patch is for trunk and the 1.8 branch.

Comment 4

[Mats Palmgren (inactive)]

Attachment: Patch rev. 1 (1.8.0 branch)

Comment 5

[Mats Palmgren (inactive)]

mozilla/widget/src/gtk2/nsWindow.cpp 	1.232 

-> FIXED

Comment 6

[Olivier]

I don't see the checkin on branch, and wonder if it got forgotten (as this bug is now closed).

Sorry for the spam if I missed something, and thanks a lot for the super-quick fix.

Comment 7

[Mats Palmgren (inactive)]

The Status field tracks status for trunk.  "fixed1.8.1.x"/"fixed1.8.0.x"
will be added to Keywords when the checkin is made for Firefox 2.0.0.x/1.5.0.x
Here are the trunk builds to test:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Comment 8

[Daniel Veditz [:dveditz]]

Comment on attachment 283660 [details] [diff] [review]
Patch rev. 1 (trunk and 1.8)

approved for 1.8.1.10, a=dveditz for release-drivers

Comment 9

[Daniel Veditz [:dveditz]]

Comment on attachment 283661 [details] [diff] [review]
Patch rev. 1 (1.8.0 branch)

approved for 1.8.0.14, a=dveditz for release-drivers

Comment 10

[Mats Palmgren (inactive)]

mozilla/widget/src/gtk2/nsWindow.cpp 	1.145.2.14 	MOZILLA_1_8_BRANCH  

mozilla/widget/src/gtk2/nsWindow.cpp 	1.145.2.1.4.4 	MOZILLA_1_8_0_BRANCH  

Comment 11

[Carsten Book [:Tomcat]]

verified fixed 1.8.1.10 using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.10) Gecko/2007111504 Firefox/2.0.0.10 and the steps to reproduce from this bug.

Comment 12

[Al Billings [:abillings - ex-MoCo]]

I'm not noticing any real difference between the last released 1.8.0 FF build (1.5.0.12) and the current nightly, where this is "fixed".

Comment 13

[Daniel Veditz [:dveditz]]

Attachment: zipped testcase

Saved original testcase in case server goes away.