187654 - Binary files sent as [text/plain] crashes xft-enabled Mozilla

Status: RESOLVED DUPLICATE of bug 186704

(SeaMonkey :: General, defect)

Description

[Max Gilead]

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.

Comment 1

[Max Gilead]

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

Comment 2

[Andrew Schultz]

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?

Comment 3

[Max Gilead]

- 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?

Comment 4

[Andrew Schultz]

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.

Comment 5

[Kenneth Herron]

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.

Comment 6

[David A. Pérez]

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

Comment 7

[James Strandboge]

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!

Comment 8

[James Strandboge]

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

Comment 9

[André Dahlqvist]

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

Comment 10

[André Dahlqvist]

Attachment: Backtrace of crash when accessing binary file on xft-enabled build.

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

Comment 11

[André Dahlqvist]

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

Comment 12

[André Dahlqvist]

Attachment: Backtrace of crash on a debug build

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.

Comment 13

[Christopher Blizzard (:blizzard)]

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

Comment 14

[André Dahlqvist]

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

Comment 15

[Christopher Blizzard (:blizzard)]

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.

Comment 16

[André Dahlqvist]

Attachment: Backtrace when mozilla runs with --sync

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]).

Comment 17

[Christopher Blizzard (:blizzard)]

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