Closed Bug 270777 Opened 21 years ago Closed 20 years ago

Mozilla makes XFree86 take all the available memory and crashes

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED EXPIRED

People

(Reporter: vincent-moz, Unassigned)

References

(
URL
)

Details

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.
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.
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.
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.
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.
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
Closed: 21 years ago
Resolution: --- → DUPLICATE
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 → ---
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?
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.
try: pushd /home/lefevre/mozilla/lib/mozilla-1.8a5/; ./mozilla -g run
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.
erm, where mozilla or which mozilla? where is it? how about: ./run-mozilla.sh -g ./mozilla-bin
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?
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".
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?
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?
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
Closed: 21 years ago → 20 years ago
Resolution: --- → EXPIRED
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.