188581 - Increasing memory usage of X when viewing jpg images in Mozilla until crash

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[Todd Geders]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021231
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021231

When viewing ~700 kB jpeg images, each time you click on a new image,
memory usage of X goes up 12 MB (based off of command 'top -d.5' and pressing M
to sort by memory usage).  However, when clicking back button and subsequently
viewing another ~700 kB jpeg image, memory usage of X goes up by another 12 MB.

This continues until all available RAM (256MB) is used and then swap begins to
be filled.  No noticable slowdowns occur.  However, once most of the swap is
full (1 GB in my case) Mozilla will freeze and crash.  Immediately after
crashing, memory used by X returns to a low value (32MB in my case).  This
occurs with BOTH mozilla and phoenix.  

While using Konqueror, this problem does not occur.  Increase in memory usage of
X by 12MB does occur, but the memory seems to be flushed every 4-6 images.  This
seems to be the proper behaviour we should see.

This has been confirmed on other Gentoo boxes (don't have other Linux boxes to
see if it is distro dependant).  Using Mozilla 1.2.1 and Phoenix 0.5. 
I can provide any other necessary details if needed.

Often once it begins using swap, mozilla will freeze using all available CPU and
slowly consume all available system memory/swap until dying once no memory is
available or I kill mozilla-bin.

KDE 3.0.5a, XFree86 4.2.1, nVidia graphics, driver 31.23, kernel 2.4.19,
otherwise extremely stable.  I do notice an increasing memory usage, but
problems only occur when I view only images (not really while viewing pages with
images embedded).

Reproducible: Always

Steps to Reproduce:
1.  Go to http://expert.ics.purdue.edu/~wu01/TRIP_CA/
2.  Click on image, then click back button.  Repeat with different image.
3.  Monitor memory usage by running 'top -d.5' and pressing M to sort by memory
size.  mozilla-bin and X should be top two.  X increases by 12MB each image, but
is never released unless you close Mozilla or it crashes.

Actual Results:  
Memory usage of X increased until all available RAM was used.  Swap was used
then until anywhere between half used and completely used (1GB swap partition),
after which Mozilla would freeze, use all available CPU, and increase memory
usage until it crashes or I kill it.

Expected Results:  
What Konq does...increases memory allocation of X for first 4-8 images, then
bring the usage back down or at least limit the number of cached images to 4-8
(50 to 100MB)

Comment 1

[Olivier Cahagne]

can you post Talkback ID for this crash
"mozilla/bin/components/talkback/talkback" or a stack trace using  GDB on a
debug build ?

Comment 2

[Olivier Cahagne]

wfm using build 2003011008 on Linux.
Can you try again using latest nightly build ?
http://ftp.mozilla.org/pub/mozilla/nightly/latest-trunk

Comment 3

[R.K.Aa.]

similar reports in bug 174760, bug 157187 and seems to be fixed on the trunk in
bug 179498.

Reporter: Can you reproduce the bug with 1.3* builds from after Dec. 13th?

Comment 4

[Todd Geders]

Tried Mozilla 1.3a from Dec 13th, and now the crashing no longer occurs, and
everything remains stable.  HOWEVER, it still does not release the memory, and
consequently you get a functionally useless machine when it runs out of memory
(256MB RAM + 1 GB swap).  X now claims to be using 1418MB of memory, and the
disk thrashing is horrible...the mouse still responds, but I cannot get mozilla
to close after waiting 30 minutes, so I had to powercycle the box.  

I will be trying a nightly build later today, but I can only compile so
quickly...

Comment 5

[Todd Geders]

Problem completely fixed in latest nightly build.  I guess I just have to wait
for 1.4 to be released.

Comment 6

[Olivier Cahagne]

Marking WFM as per reporter comments.