crash when browsing with file-picker and dir has a filename with non-ASCII character (\361 on Linux).

RESOLVED DUPLICATE of bug 225125

Status

()

--
critical
RESOLVED DUPLICATE of bug 225125
15 years ago
15 years ago

People

(Reporter: ff_mitch, Assigned: jag-mozilla)

Tracking

({crash, hang})

Trunk
x86
Linux
crash, hang
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20030917
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20030917

Mozilla crashes when FilePicker sees a file with non ASCII characters. This
happens whenever FilePicker is used (Download dialog, File Open dialog, etc.)

This does not happen with 1.4

Reproducible: Always

Steps to Reproduce:
1. Create a file in Linux that has a non standard ASCII character:
touch blah-$'\361'.txt
2. Start Mozilla,
3. Choose File->Open File...
4. Browse to directory where new file was created


Actual Results:  
File Picker takes throttles a little (~1 sec) and then Mozilla crashes hard.

Expected Results:  
Not Crash, read directory properly inserting ? where characters are not understood.
(Reporter)

Comment 1

15 years ago
After doing some additional testing, crash does not happen with example. Special
character needs to be at position 40 to 70 (name of file needs to be 40+
characters long and has to have the special character above position 39). 

When filename is 70+ characters long and special character are above position
70, mozilla freezes but does not crash.

Updated

15 years ago
Keywords: crash

Updated

15 years ago
Keywords: hang

Comment 2

15 years ago
I believe I can verify that browsing to a directory with a file with
'questionable' characters will crash firebird 0.7.  Some program generated a
dotfile cache from a filename that had extended ascii characters.  The original
file with extended ascii characters is tolerated, so I'm assuming whatever
generated the dotfile version of the filename didn't correctly handle them,
resulting in some non-ascii characters.  Unfortunately I deleted the file rather
than just moving it, so I can't verify.
(Reporter)

Comment 3

15 years ago
Created attachment 133786 [details]
stderr output of mozilla from start up to crash

I added the stderr output that mozilla generates when the crash happens. This
should help with debugging.
(Reporter)

Comment 4

15 years ago
Created attachment 133787 [details]
stdout of mozilla when crash occurs

I've included also the stdout of Mozilla when the crash happens.
bz made a patch for a very similar bug, but I can't find it right now...
Whiteboard: DUPEME
(Reporter)

Comment 6

15 years ago
There is a workaround for this bug. Simply start mozilla with LC_ALL or LC_CTYPE
set to something other than "C", "POSIX".

Under Linux, with bash (or any sh-based shell):
LC_CTYPE="en_US" mozilla
or
LC_ALL="fr_CA" mozilla
Dup, indeed.  The original explains the magic number "40", as well as why
changing locale settings helps.

*** This bug has been marked as a duplicate of 225125 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.