302858 - Memory leak with loaded image

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050731
Firefox/1.0+ ID:2005073112

repro:
1. Close FF and open a single window with single tab
2. Open task manager and click on the tab "performance"
3. Open the file (4000px by 2000px meteosat image = 2.5Mb)
4. Watch the image fully load and look at task manager
--the memory usage will start growing and growing
--at some point the processorload jumps to 100% and hangs there
--every second the memusage jumps another 10 Mb
--in the "application" tab of taskmanager Firefox.exe gets alternating status,
running and not responding
--Though the image is fully loaded (scrolling is possible during some intervals)
the memusage keeps growing.
--closing the tab (replacing it with a blank one) does not stop the process
5.In most (test)cases I needed to kill the process, a few times i managed to
close the browser.

AMD-850/512Mb mem.
(This is NOT a resession)

Comment 1

[Dave Townsend [:mossop]]

WFM
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050731
Firefox/1.0+ ID:2005073112

Comment 2

[Peter B]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050726
Firefox/1.0+ ID:2005072612

No problems here.

Comment 3

[Peter B]

Ignore #2. Didn't see Dave's comment...

Comment 4

[Ria Klaassen (not reading all bugmail)]

I see also this behaviour but only and 100% consistently on one particular system.

Comment 5

[Ria Klaassen (not reading all bugmail)]

Regressed between ID:2005061306 and ID:2005061406.

Comment 6

[Peter van der Woude [:Peter6]]

(In reply to comment #4)
> I see also this behaviour but only and 100% consistently on one particular system.
Indeed, on the AMD-850 it goes wrong, if i use the PIII-1400 with same grapfics
card/driver/mem it works just fine

Comment 7

[Dave Townsend [:mossop]]

For reference, my system is AMD Athlon 2200, nVidia GeForce 4 MX, 1GB RAM.

Comment 8

[Peter van der Woude [:Peter6]]

(In reply to comment #5)
> Regressed between ID:2005061306 and ID:2005061406.
Thanks a lot Ria.

To be exact, it 
works in the 20050613 2334pdt build
fails in the 20050614 0145pdt build
checkins:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&filetype=match&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-06-13+22%3A45%3A00&maxdate=2005-06-14+01%3A30%3A00&cvsroot=%2Fcvsroot

cc: Vlad , the checkin for bug 109672 seems the only likely candidate.
(the others are NPOB - Xforms)

Comment 9

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Can we get a backtrace during the 100% cpu usage time?  I don't think 109672
caused this directly, but possibly in concert with the new code that generates
favicons for images.

Comment 10

[Peter van der Woude [:Peter6]]

btw, if the image is loaded in a background tab and you wait to open it till
it's fully loaded there is no problem at all.

Comment 11

[Peter van der Woude [:Peter6]]

Attachment: screenshot taskmaner during the whole period of activity

Comment 12

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Still need a stack trace during that 100% CPU spike period.. I can't even try to
reproduce until I get back to someplace with a sane internet connection (can't
download a new build, unless I leave it overnight :p)

Comment 13

[Stuart Parmenter]

Afaik, we don't actually scale images down manually and save a cached
small-sized favicon for them, so we'd be redrawing that favicon image from the
large image and scaling it down every time we repaint that area, which is pretty
often.  The favicons should probably scale the actual image down and store that
instead of the full sized image.

Comment 14

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Scaling down should be fast and cheap (since we just skip pixels, AFAIK, we
don't interpolate at all)... so it's not that specifically.

Comment 15

[Mike Schroepfer]

Will take patch for beta - but not a blocker

Comment 16

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I can't reproduce with a 2GHz Sempron, 1GB RAM, nvidia 6800GT (256mb ram). 
Switching between tabs with a bunch of large images open (including the testcase
one here) is responsive, and I don't see any memory leaks.. would be nice to get
some more samples of people who are seeing this bug, to see if there's some
particular hardware combo that's causing it.  Information needed would be:  CPU
type and speed, system memory, graphics card, graphics card memory.

Comment 17

[David Harper]

I can see this bug:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050823
Firefox/1.0+ ID:2005082307

Athlon XP 2500+, 1GB RAM, ATI Radeon 9600SE (128MB)

The memory jumped up 40MB when loading the image, while the CPU hovered around
50%. When the image finished loading, the memory went back down again, but the
CPU jumps to 99% and stays there. 

Comment 18

[Peter van der Woude [:Peter6]]

bug 304561 fixed this one too (removing the icon for huge images)
->Fixed