171681 - Closing tabs/windows containing large images does not free memory

Status: RESOLVED DUPLICATE of bug 179498

(Core :: Graphics: ImageLib, defect)

Description

[Radoslaw Sokol]

Mozilla build 2002092808 on WinNT 4.0 SP6a. Clean upgrade (previous
build uninstalled, remaining files erased, 2002092808 installed, new
profile added).

Steps to reproduce:
1. Open a site containing large images (I tested it on PNG screenshots
   of 1024x768 size (or larger))
2. Open an image in a separate tab/window
3. Look at the Private Bytes counter in Performance Monitor
   for mozilla.exe -- it grows accordingly
3. Close that tab/window -- Private Bytes counter for mozilla.exe
   drops only a little, leaving megabytes of memory leaked

Expected result:
1. Shortly after closing the tab/window containing an image
   Private Bytes should drop to the previous level

It DOES NOT happen if opening the same image twice: it seems
like getting an image from cache does not trigger allocating new
memory block.

I've just managed to raise Private Bytes from 11 MB to 45 MB
simply by looking at all screenshots of RedHat 8.0 from today's
edition of http://www.osnews.com/.

Comment 1

[Radoslaw Sokol]

Correction: images that cause the problem are plain JPEGs,
not PNGs. Same wrong behavior observed on 2002092908, too.

Comment 2

[Boris Zbarsky [:bzbarsky]]

What is your memory cache size set to?

Comment 3

[Radoslaw Sokol]

4096 KB on test profile (a clean one) and 1024 MB on my
personal one (upgraded from previous builds). Both profiles
show the same behavior (private memory allocation far exceeds
the cache size). BTW memory allocation per one image suggests,
that "leaked" memory belongs to the uncompressed form of the
image, rather than the cache (one image can leak several MBs
of memory, while the JPG itself is 200 KB in size).

Comment 4

[Radoslaw Sokol]

My personal profile's cache size is 1024 _KB_, of
course. Sorry for the typo :(

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

memory cache does cache uncompressed images.

Comment 6

[Radoslaw Sokol]

Screenshot of Performance Monitor showing these
"memory allocation steps":

http://213.76.162.19/mozilla_bug.gif

Every step corresponds to one image open for few
seconds and then closed. Five different images
were opened. Opening an already viewed image
does not create such "memory allocation step".

Comment 7

[Boris Zbarsky [:bzbarsky]]

One other question.  How much RAM does your graphics card have?

Comment 8

[Radoslaw Sokol]

4 MB (Diamond Viper v330, latest Diamond drivers)
Does it have any impact on Mozilla's image processing?
Personally I doubt it :)

BTW I tried to disable memory cache in preferences
with very interesting results: opening same images
consumed about twice as much memory as it did before;
closing the image freed _half_ of the memory. Re-opening
same image caused that "double" block of memory to be
allocated _again_, what did not happen with memory
cache enabled. Once again, closing the image freed
only half of the newly allocated block.

So, as long as the memory cache is on, viewing the screenshots
at http://www.osnews.com/story.php?news_id=1842
causes only one memory leak per image. With memory cache
disabled, there is one memory leak per view.

I can post a screenshot of Performance Manager's Private
Bytes chart with Mozilla's Memory Cache turned off, if
it helps.

Comment 9

[Boris Zbarsky [:bzbarsky]]

The video card affects it because we store things in the video RAM directly. 
But you don't have 64MB of video ram.  ;)

To imagelib to figure out what's up.

Comment 10

[Christian Hamacher]

Could this be related to / a duplicate of bugs 131456, 149607, 98835, 157187?

CC-> self

Comment 11

[Radoslaw Sokol]

Could be. However, I can't confirm it for HTML code alone
(I haven't tested it thoroughly) but I am quite sure that
images leak memory. Even WWW pages with simple graphical
elements make Private bytes stay at the level higher than
before loading the page -- and it becomes easy to observe
when it comes to huge images, able to consume megabytes
of memory in one step.

The same happens with recent Phoenix builds.

Comment 12

[John Morrison]

This is for real.

Comment 13

[_pwg_]

Have noticed this too on build 2002101008 on Win2k SP2. After opening images in
tabs and closing tabs, memory not being released. Eventually system runs out of
virutal memory and browser window becomes corrupt - tabs & toolbars disappear. 
I can make the browser window smaller (is normally maximised on my pc) and I can
then see the tabs & toolbars again.

Physical Memory: 256MB
Video card: 64MB
Memory cache: 8196KBytes

Comment 14

[Dvir]

Something has definitely regressed since 1.1 . With nightly builds today I can't
browse image intensive sites for long. I usually open many windows with many
tabs in them. In 1.1 I can browse like this for hours, all the time closing and
opening new tabs.
With current builds, when the memory usage of Mozilla gets to aroung 70-80MB (I
have 256MB total) screens get corrupted, and clicking on a tab/window does not
display the image in that tab. Ot's happening for me on Windows XP.

It seems that this bug is closely related to 131456, but I'm not sure it's the
same problem.

Comment 15

[Radoslaw Sokol]

> Something has definitely regressed since 1.1 .

Exactly. I've just installed 1.0.1 release and it manages
to free memory allocated for large images.

I observed that Mozilla 1.0.1 releases memory _right
after_ having finished _downloading_ image. The image
shows up (complete) in the browser window and memory
allocation drops momentarily. So, my first bug description
needs correction: last Mozilla builds (the wrong behaviour
is still present in 2002111804) fail to free memory on
image download completion (not on closing tab/window).

I hope this bug will get fixed till 1.2 release -- it
makes using the browser rather impossible.

Comment 16

[Radoslaw Sokol]

Bug still found in 1.2 final.
Easy way to reproduce:
1. Start Mozilla
2. Open http://www.gnome.org/
3. Click "See Gnome in action"
4. Take note of Mozilla's memory usage
5. Open three or four screenshots in separate tabs
6. Wait for the images to show up and then close the tabs
7. Compare current memory usage with previous one
Expected results:
 - memory usage after closing images should be close to the
   previous one
Actual results:
 - 15 MB of private memory gone

Comment 17

[Harshal Pradhan]

This is may be a dup of bug 179598 (which I recently fixed). Can someone who was
seeing this please try a recent trunk nightly and confirm that the leak is gone.

Comment 18

[Radoslaw Sokol]

Can't believe my eyes ;) but in /latest/ 2002121408 build
the leak seems to be gone. I performed my "GNOME-test"
described above and closing all images released associated
memory. Good work!

Mozilla still leaks memory on complex pages, but now I would
blame bugs mentioned by Christian Hamacher, as I am pretty
sure that images no longer leak memory.

Comment 19

[Harshal Pradhan]

err, s/dup of bug 179598/dup of bug 179498 in my comment above.

*** This bug has been marked as a duplicate of 179498 ***