Mozilla makes XFree86 take all the available memory and crashes

RESOLVED EXPIRED

Status

SeaMonkey
General
--
critical
RESOLVED EXPIRED
13 years ago
4 years ago

People

(Reporter: Vincent Lefevre, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a5) Gecko/20041018
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a5) Gecko/20041018

With the above URL, Mozilla makes XFree86 take all the available memory and
crashes (due to lack of memory?). However, I don't know if this is a Mozilla bug
or a XFree86 bug or a bug in some library, but since Mozilla is the cause, I'm
reporting the bug here.

Reproducible: Always
Steps to Reproduce:
1. Open the above URL and wait for a few dozens of seconds.
Actual Results:  
A lot of swapping. The top command shows that XFree86 takes more and more RES
memory. Then Mozilla crashes.

Expected Results:  
Mozilla should display the page.

Comment 1

13 years ago
This is plainly a really badly written page. It's 291K long with 236 images on
average 300x300 dimensions making it consume about 170MB's of memory (assuming
8bit color). I doubt you'd get better rendering on any platform.

laptop ~% ls -l pianos.html
-rw-r--r--    1 mitch    wheel      294742 Nov 18 06:18 pianos.html
laptop ~% du -h pianos.html
292K    pianos.html
laptop ~% grep IMG pianos.html|wc -l
    236

The fix in bug 210931 would probably trap it.
(Reporter)

Comment 2

13 years ago
It is a badly written page, but Opera 7.54 renders it correctly (on the same
machine) and very quickly. I've also been told that Firefox has no problem with it.

Comment 3

13 years ago
I'm surprised if it worked on Firefox on the same machine since they
(mozilla/firefox) both use the same (Gecko) rendering engine. As for Opera i'm
unsure what they are doing differently to render it. BTW, it does render
perfectly on my machine too using mozilla - i've got 1GB memory, so it's not an
issue with mozilla.
(Reporter)

Comment 4

13 years ago
Concerning Firefox, it was on another machine (but its user didn't tell me the
corresponding configuration).

> i've got 1GB memory, so it's not an issue with mozilla.

Could you see Xfree86 taking more RES memory with "top" (or some other utility)
while loading the page?
Product: Browser → Seamonkey
Vincent, when I load that page with a current trunk Mozilla build (pulled this
morning from CVS), using XFree86 4.3, I see X memory usage go up to about 650MB,
but the page loads fully, with no crash....  Quitting mozilla makes memory usage
for X go down to 189MB or so.

Note that we store images server-side, so all that really indicates is that this
page has about 500MB of images on it (size measured after the images are decoded
into bitmaps).

How much memory does Firefox take on this page on your machine, our of
curiousity?  I'd assume it's the same as suite, but if it's different, please
let me know.
(Reporter)

Comment 6

13 years ago
Firefox is not installed on this (old) machine, but I could try with my new
machine, and it has the same problem: X takes 29MB before loading the page,
508MB after loading it, and back to 29MB after quitting Firefox. My old machine
has 256MB memory (128MB physical + 128MB swap); this explains the crash.

This seems to be a bug in XFree86 as well, but I really don't think that Mozilla
should send so much to the X server; there should be a limit, possibly chosen by
the user depending on its configuration. The browser shouldn't make the system
unstable (e.g. filling the memory) just because a page is not well written (and
perhaps it is not so badly written since Opera doesn't have any problem with it).

Mozilla/Firefox shouldn't assume that there is much memory either. Firefox is
also used on the latest Zaurus PDAs, where there is "only" 64MB available RAM.

*** This bug has been marked as a duplicate of 228245 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 8

13 years ago
I'm reopening the bug since there are in fact two related but independent bugs:
the requested enhancement (bug 228245) to avoid a memory shortage and the crash,
which is not necessarily due to a memory shortage on Mozilla's side. Concerning
this latter bug, I've just tried with a remote X11 server: when this server has
no longer memory, it returns a BadAlloc error and Mozilla crashes:

dixsept:~> mozilla
The program 'Gecko' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 37800 error_code 11 request_code 53 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

In case of a BadAlloc error, Mozilla shouldn't crash, but should try to recover
from this error, by disabling images for the concerned page for instance, or at
least the minimum so that the user doesn't lose data due to a crash.

Note: on the machine where the Mozilla program is launched, there's plenty of
memory, so that there isn't any reason for doing anything wrong.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
(Reporter)

Comment 9

13 years ago
It could be a dup of bug 40931, but I'm not sure what this bug is about: try to
avoid the BadAlloc (when possible) or avoid the crash.
Does Mozilla actually crash?  Or does GDK helpfully call exit() like it tends to
when an X error happens?  What happens if you run under a debugger and cause
this to happen?
(Reporter)

Comment 11

13 years ago
No core dump is generated, but I don't know how Mozilla is terminated.

When I try to run "mozilla --debug" and type "run" in gdb (I'm not sure that
this is the right thing to do), I get:

Starting program: /home/lefevre/mozilla/lib/mozilla-1.8a5/mozilla-bin 
(no debugging symbols found)
/home/lefevre/mozilla/lib/mozilla-1.8a5/mozilla-bin: error while loading shared
libraries: libxpcom_core.so: cannot open shared object file: No such file or
directory

Program exited with code 0177.

though everything is fine without the --debug.

Comment 12

13 years ago
try:
pushd /home/lefevre/mozilla/lib/mozilla-1.8a5/; ./mozilla -g
run
(Reporter)

Comment 13

13 years ago
I don't have a mozilla file in /home/lefevre/mozilla/lib/mozilla-1.8a5, and if I do

pushd /home/lefevre/mozilla/lib/mozilla-1.8a5/
mozilla -g
run

I get the same error.

Comment 14

13 years ago
erm, where mozilla or which mozilla? where is it?

how about:
./run-mozilla.sh -g ./mozilla-bin
(Reporter)

Comment 15

13 years ago
Same problem with

./run-mozilla.sh -g ./mozilla-bin
run
> I don't have a mozilla file in /home/lefevre/mozilla/lib/mozilla-1.8a5

Er..  Then why is mozilla-bin there?   What sort of install is this?

What's your MOZILLA_FIVE_HOME environment variable set to?  Where is
libxpcom_core.so located?
(Reporter)

Comment 17

13 years ago
I always do my installations with "make install" (the standard way to do...).
MOZILLA_FIVE_HOME is unset (this is the goal of the run-mozilla.sh script to set
it). libxpcom_core.so is in "/home/lefevre/mozilla/lib/mozilla-1.8a5".

Note: the mozilla script is in "/home/lefevre/mozilla/bin".
(Reporter)

Comment 18

13 years ago
Also, when running mozilla -g, the following is printed out:

/home/lefevre/mozilla/lib/mozilla-1.8a5/run-mozilla.sh -g
/home/lefevre/mozilla/lib/mozilla-1.8a5/mozilla-bin
MOZILLA_FIVE_HOME=/home/lefevre/mozilla/lib/mozilla-1.8a5
LD_LIBRARY_PATH=/home/lefevre/mozilla/lib/mozilla-1.8a5:/home/lefevre/mozilla/lib/mozilla-1.8a5/plugins:/home/lefevre/mozilla/lib/mre/mre-1.8a5:/home/lefevre/i686-linux/lib:/home/lefevre/i686-linux/lib:/users/spaces/logiciels/mpfr-2.0.2/linux/lib:/users/spaces/logiciels/gmp/linux/lib:/users/spaces/logiciels/mathlib/linux/lib
DISPLAY=:0.0
XPSERVERLIST=:64 
DYLD_LIBRARY_PATH=/home/lefevre/mozilla/lib/mozilla-1.8a5:/home/lefevre/mozilla/lib/mre/mre-1.8a5
LIBRARY_PATH=/home/lefevre/mozilla/lib/mozilla-1.8a5:/home/lefevre/mozilla/lib/mozilla-1.8a5/components:/home/lefevre/mozilla/lib/mre/mre-1.8a5:/home/lefevre/i686-linux/lib:/home/lefevre/i686-linux/lib:/users/spaces/logiciels/mpfr-2.0.2/linux/lib:/users/spaces/logiciels/gmp/linux/lib:/users/spaces/logiciels/mathlib/linux/lib
SHLIB_PATH=/home/lefevre/mozilla/lib/mozilla-1.8a5:/home/lefevre/mozilla/lib/mre/mre-1.8a5
LIBPATH=/home/lefevre/mozilla/lib/mozilla-1.8a5:/home/lefevre/mozilla/lib/mre/mre-1.8a5
       ADDON_PATH=/home/lefevre/mozilla/lib/mozilla-1.8a5
      MOZ_PROGRAM=/home/lefevre/mozilla/lib/mozilla-1.8a5/mozilla-bin
      MOZ_TOOLKIT=
        moz_debug=1
     moz_debugger=
/usr/bin/gdb /home/lefevre/mozilla/lib/mozilla-1.8a5/mozilla-bin -x /tmp/mozargs4413
GNU gdb 6.3-debian
[...]

and the variables are exported by run-mozilla.sh:

export MOZILLA_FIVE_HOME LD_LIBRARY_PATH
export SHLIB_PATH LIBPATH LIBRARY_PATH ADDON_PATH DYLD_LIBRARY_PATH
Does it help if you run the mozilla from dist/bin in your objdir instead of the
installed one?
(Reporter)

Comment 20

13 years ago
Same problem:

dixsept:.../mozilla/dist/bin> ./mozilla -g
./run-mozilla.sh -g ./mozilla-bin
MOZILLA_FIVE_HOME=.
 
LD_LIBRARY_PATH=.:./plugins:/home/lefevre/mozilla/lib/mre/mre-1.8a5:/home/lefevre/i686-linux/lib:/home/lefevre/i686-linux/lib:/users/spaces/logiciels/mpfr-2.0.2/linux/lib:/users/spaces/logiciels/gmp/linux/lib:/users/spaces/logiciels/mathlib/linux/lib
DISPLAY=:0.0
XPSERVERLIST=:64 
DYLD_LIBRARY_PATH=.:/home/lefevre/mozilla/lib/mre/mre-1.8a5
    
LIBRARY_PATH=.:./components:/home/lefevre/mozilla/lib/mre/mre-1.8a5:/home/lefevre/i686-linux/lib:/home/lefevre/i686-linux/lib:/users/spaces/logiciels/mpfr-2.0.2/linux/lib:/users/spaces/logiciels/gmp/linux/lib:/users/spaces/logiciels/mathlib/linux/lib
       SHLIB_PATH=.:/home/lefevre/mozilla/lib/mre/mre-1.8a5
          LIBPATH=.:/home/lefevre/mozilla/lib/mre/mre-1.8a5
       ADDON_PATH=.
      MOZ_PROGRAM=./mozilla-bin
      MOZ_TOOLKIT=
        moz_debug=1
     moz_debugger=
/usr/bin/gdb ./mozilla-bin -x /tmp/mozargs4591
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-linux"...(no debugging symbols found)
Using host libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) run
Starting program: /home/lefevre/software/moz-source/mozilla/dist/bin/mozilla-bin 
(no debugging symbols found)
/home/lefevre/software/moz-source/mozilla/dist/bin/mozilla-bin: error while
loading shared libraries: libxpcom_core.so: cannot open shared object file: No
such file or directory

Program exited with code 0177.
Any chance you could do a debug build and see whether it actually gives you a
stack when this error happens?
(Reporter)

Comment 22

13 years ago
Here's what I get with a debug build (from last night), just after opening the
culprit URL:

The program 'Gecko' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 67462 error_code 11 request_code 53 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
nsStringStats
 => mAllocCount:          37833
 => mReallocCount:        12578
 => mFreeCount:           32266  --  LEAKED 5567 !!!
 => mShareCount:          31548
 => mAdoptCount:           3172
 => mAdoptFreeCount:       3026  --  LEAKED 146 !!!
zsh: exit 1     mozilla
Yeah, that's not a crash.  That's GDK helpfully calling exit() when it gets an X
error instead of reporting the error to the app and letting the app deal...

I'm pretty sure we have this reported already, and probably invalid (since it's
a bug or design decision or whatever in GDK).
Whiteboard: DUPEME
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago12 years ago
Resolution: --- → EXPIRED

Updated

4 years ago
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.