Max Gilead Reporter
	Description • 22 years ago

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

I've just hit a serious problem trying to download small (5MB) file in SHAR
format. Mozilla crashed instead of starting a download.

To reproduce paste this URL to address field:
ftp://gd.tuwien.ac.at/opsys/linux/java/java3d/1.3/i386/fcs/java3d-sdk-1.3-fcs-linux-i386.bin

I can see in the memory monitor how memory usage goes to the top and then
browser crashes.


Reproducible: Always

Steps to Reproduce:
1. Paste following URL into address field:
ftp://gd.tuwien.ac.at/opsys/linux/java/java3d/1.3/i386/fcs/java3d-sdk-1.3-fcs-linux-i386.bin

Actual Results:  
Mozilla crashed

Expected Results:  
Starting a download

Thre are bug reports that say about high CPU usage when Mozilla slows down or
become unresponsive after trying to download a binary file. I haven't found one
which says it crashes and goes wild eating up entire memory available.

	Max Gilead Reporter
	Comment 1 • 22 years ago

*** Bug 187653 has been marked as a duplicate of this bug. ***

	Andrew Schultz
	Comment 2 • 22 years ago

Mozilla thinks the file is text (because the beginning is text) and displays it.
 But for me, it does not crash (at least not immeadiately).

Could you provide a talkback ID for the crash?

	Max Gilead Reporter
	Comment 3 • 22 years ago

- Using latest Mozilla build from
ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-i686-pc-linux-gnu.tar.gz
Symptoms as described. No talkback support.

- Tried to install talkback.xpi from mozilla-i686-pc-linux-gnu-sea.tar.gz
package but it didn't change anything.

- Downloaded
ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-i686-pc-linux-gnu-sea.tar.gz
and performed Complete install.
Sometimes (not always!) Mozilla displays beginning of the file and then
everything happens as before - memory indicator goes to the top, browser crashes.

No talkback info was available in either case. I tried to launch mozilla
directly as binary, using run-mozilla.sh, also tried to launch talkback manually
without success.

Should I do something special to make talkback active?

	Andrew Schultz
	Comment 4 • 22 years ago

talkback doesn't always work.  talkback usually doesn't work on linux anyway.

=> Browser / General.  Mozilla never makes it to file handling because it thinks
the file is text.  Most likely, Mozilla thinks the binary is multi-byte
international characters and confusing itself.

	Kenneth Herron
	Comment 5 • 22 years ago

Using linux nightly 2003010404. Works for me. Mozilla managed to download &
display the entire file; afterwards, "top" reported that mozilla's memory usage
was only around 60-62 MB.

	David A. Pérez
	Comment 6 • 22 years ago

This problem has stoped after deleting the file XUL.mfl on my profile.

	James Strandboge
	Comment 7 • 22 years ago

This happened to me by clicking on:
http://www.mit.edu/afs/athena/user/d/a/daveg/Src/ATHENA/third/gnome-system-monitor/po/am.gmo

Mozilla 1.2.1 built with gcc 2.95 and libc6 2.2.5 on debian woody.

No errors-- click that link and poof!

	James Strandboge
	Comment 8 • 22 years ago

The crash only occurs if mozilla-xft is installed.  If xft is not installed then
mozilla does not crash.

	André Dahlqvist
	Comment 9 • 22 years ago

Confirming on a xft-enabled Mozilla build. I have been seeing this also on
binary files (served wrongly as [text/plain]). I agree with the conclusion that
it only happens on xft-enabled builds, because I believe it started happening
when I switched to that.

I'll try to get a backtrace of this crash if possible. Another URL that crashes
for me is:

http://jota.sm.luth.se/~anedah-9/misc/george.ogg

	André Dahlqvist
	Comment 10 • 22 years ago

Here is the gdb backtrace. If needed I can compile my own debug build to get a
better backtrace.

	André Dahlqvist
	Comment 11 • 22 years ago

CC:ing blizzard since the backtrace points to xft and he is the xft guru.

	André Dahlqvist
	Comment 12 • 22 years ago

Here is the backtrace that happens on the george.ogg file above, but reproduced
on a debug build. I hope it contains more valuable information.

	Christopher Blizzard (:blizzard)
	Comment 13 • 22 years ago

Are these backtraces done using --sync by any chance?

	André Dahlqvist
	Comment 14 • 22 years ago

No, I wasn't even aware there was such a flag to Mozilla.

	Christopher Blizzard (:blizzard)
	Comment 15 • 22 years ago

It's not actually a flag for Mozilla.  It's a flag for the underlying toolkit
which tells it to run Xlib in synchronous mode.  Normally, xlib runs
asyncronously for performance reasons and the error that you're seeing might
actually have been generated in an entirely different piece of code.  That's why
I'm asking you to run Mozilla with --sync so that I can see where it's actually
crashing.

	André Dahlqvist
	Comment 16 • 22 years ago

I cannot get the debug build to crash when I run mozilla with --sync, instead
it just hangs. This attachment is therefore the backtrace from my regular
optimized build (same build as used for attachment 1 [details] [diff] [review]).

	Christopher Blizzard (:blizzard)
	Comment 17 • 22 years ago

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