crash in NS_WildCardMatch when navigating with filepicker to a file with non-ascii name

RESOLVED FIXED in mozilla1.2alpha

Status

()

--
major
RESOLVED FIXED
17 years ago
17 years ago

People

(Reporter: aleksander.adamowski, Assigned: shanjian)

Tracking

({crash})

Trunk
mozilla1.2alpha
x86
Linux
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

17 years ago
Build ID: 2001112308
Reproducible: Always

To reproduce:
1. Unpack the testcase with tar (tar -zxvf test.tgz)
2. Launch Mozilla
3. select File->Open (or take any other steps necessary to bring up the filepicker)
4. Navigate to the directory named test that was unpacked from test.tgz

What happens:
Mozilla segfaults and dumps core, talkback doesn't fire up.

I'll include a full backtrace from gdb soon.
Meanwhile, here's a snippet from gdb bt with what I think is most significant:

#0  0x41487e88 in NSGetModule ()
   from /usr/local/mozilla/components/libfileview.so
#1  0x4148829d in NSGetModule ()
   from /usr/local/mozilla/components/libfileview.so
#2  0x414874b8 in NSGetModule ()
   from /usr/local/mozilla/components/libfileview.so
#3  0x41486b21 in NSGetModule ()
   from /usr/local/mozilla/components/libfileview.so
#4  0x40150b61 in XPTC_InvokeByIndex () from /usr/local/mozilla/libxpcom.so
#5  0x4086d049 in NSGetModule ()
   from /usr/local/mozilla/components/libxpconnect.so
#6  0x40872a05 in NSGetModule ()
   from /usr/local/mozilla/components/libxpconnect.so
#7  0x40067f52 in js_Invoke () from /usr/local/mozilla/libmozjs.so
#8  0x4006f9e7 in js_Interpret () from /usr/local/mozilla/libmozjs.so
#9  0x40067fa0 in js_Invoke () from /usr/local/mozilla/libmozjs.so
#10 0x4006819c in js_InternalInvoke () from /usr/local/mozilla/libmozjs.so
#11 0x4004a70b in JS_CallFunctionValue () from /usr/local/mozilla/libmozjs.so
#12 0x40e8f435 in NSGetModule () from /usr/local/mozilla/components/libjsdom.so
#13 0x40eb8eb6 in NSGetModule () from /usr/local/mozilla/components/libjsdom.so
#14 0x40b3aae5 in NSGetModule ()
   from /usr/local/mozilla/components/libgkcontent.so
#15 0x40b3b26c in NSGetModule ()
(Reporter)

Comment 1

17 years ago
Created attachment 59198 [details]
testcase
(Reporter)

Comment 2

17 years ago
Created attachment 59199 [details]
session with gdb (including backtrace)
(Reporter)

Comment 3

17 years ago
correcting a typo in summary...
Summary: crash in NSGetModule when navigatind with filepicker to a file with non-ascii name → crash in NSGetModule when navigating with filepicker to a file with non-ascii name

Comment 4

17 years ago
could not reproduce with a trunk build from last week.  what build are you
using?  (I see 2001112308, but not sure what branch this build came from).  Do
you have a URL where you downloaded this from?
(Reporter)

Comment 5

17 years ago
It's a trunk build 
ftp://ftp.mozilla.org/pub/mozilla/nightly/latest-trunk/mozilla-i686-pc-linux-gnu-sea.tar.gz
Maybe you need to set my locale (pl_PL.UTF-8) in /etc/sysconfig/i18n.
(Reporter)

Comment 6

17 years ago
I tested it with builds from the past and determined that this is a regression t
hat occured around November 15.
Trunk build 2001111506 is ok - filepicker shows the directory's contents as
expected.
2001111521 crashes, but talkback is also launched! Check talkback report
TB38557091W.
It seems that only recent nightlies have problems with talkback on Linux...
(Reporter)

Comment 7

17 years ago
OK, talkback works with this morning's builds again, so:
with today's trunk build 2001112708 I get a crash, talkback report: TB38569497G

My exact locale settings:

[olo@tuxia olo]$ locale
LANG=en
LC_CTYPE=pl_PL.UTF-8
LC_NUMERIC=pl_PL.UTF-8
LC_TIME=pl_PL.UTF-8
LC_COLLATE=pl_PL.UTF-8
LC_MONETARY=pl_PL.UTF-8
LC_MESSAGES=en_US
LC_PAPER="en"
LC_NAME="en"
LC_ADDRESS="en"
LC_TELEPHONE="en"
LC_MEASUREMENT="en"
LC_IDENTIFICATION="en"
LC_ALL=

Filesystem where I have tested this is a reiserfs. File that causes those
problems looks like this:

[olo@tuxia test]$ ls -l
total 4
-rw-r--r--    1 olo      olo           620 lis 26 20:42 telefony_r

Comment 8

17 years ago
blame points to bryner.  

Here is the stack trace from talkback:

_shexp_match__FPCUsT0i()
NS_WildCardMatch()
nsFileView::FilterFiles()
nsFileView::SetDirectory()
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod()
XPC_WN_CallMethod()
js_Invoke()
js_Interpret()
js_Invoke()
js_InternalInvoke()
JS_CallFunctionValue()
nsJSContext::CallEventHandler()
nsJSEventListener::HandleEvent()
nsEventListenerManager::HandleEventSubType()
nsEventListenerManager::HandleEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
nsXULElement::HandleDOMEvent()
PresShell::HandleEventInternal()
PresShell::HandleEventWithTarget()
nsEventStateManager::CheckForAndDispatchClick()
nsEventStateManager::PostHandleEvent()
PresShell::HandleEventInternal()
PresShell::HandleEvent()
nsView::HandleEvent()
nsView::HandleEvent()
nsViewManager::DispatchEvent()
HandleEvent()
nsWidget::DispatchEvent()
nsWidget::DispatchWindowEvent()
nsWidget::DispatchMouseEvent()
nsWidget::OnButtonReleaseSignal()
nsWindow::HandleGDKEvent()
dispatch_superwin_event()
handle_gdk_event() 

Assignee: dougt → bryner
Summary: crash in NSGetModule when navigating with filepicker to a file with non-ascii name → crash in NS_WildCardMatch when navigating with filepicker to a file with non-ascii name
(Reporter)

Comment 9

17 years ago
Hmm, it seems that Mozilla doesn't like those 2 special characters inside
textareas. 
My previous comment was cut off at the end, so I'll just substitute those
preoblematic characters with a '?' in my console output:

[olo@tuxia test]$ ls -l
total 4
-rw-r--r--    1 olo      olo           620 lis 26 20:42 telefony_r??nych_ludzi.txt
[olo@tuxia test]$ stat telefony_r??nych_ludzi.txt 
  File: "telefony_r??nych_ludzi.txt"
  Size: 620             Blocks: 8          IO Block: 4096   Regular File
Device: 308h/776d       Inode: 30907       Links: 1    
Access: (0644/-rw-r--r--)  Uid: (  501/     olo)   Gid: (  504/     olo)
Access: Mon Nov 26 20:45:46 2001
Modify: Mon Nov 26 20:42:46 2001
Change: Mon Nov 26 20:42:46 2001


Some additional information:
The original filename displays as "telefony_ró¿nych_ludzi.txt" when accessed
through Samba shares from Windows (the client codepage is 852). On the Linux
filesystem level, however, I'm not sure what encoding is used. I suspect it's
UTF-8, but I'm far from sure.
(Reporter)

Comment 10

17 years ago
You'll need to set encoding to ISO-8859-2 in your browser in order to see the
original filename "telefony_ró¿nych_ludzi.txt" properly (as seen from Windows
clients).
(Reporter)

Comment 11

17 years ago
(set browser character coding to ISO-8859-2 to read this comment)

I've just checked that trunk build 2001111506 shows this filename as
"telefony_ró?nych_ludzi.txt" (So it seems to be the proper behaviour, the second
character is probably undisplayable and thus substituted with a question mark). 
Later builds crash as described.
CC'ing some i18n guys... I'm not sure how to configure my system to reproduce
this bug.  Could you please tell me how to do so, or even better, post a stack
trace of this crash from a debug build?

Thanks!
(Reporter)

Comment 13

17 years ago
Locale settings for the user that's running Mozilla are in comment #7.
The file that has those characters was created by a SMB client (Polish version
of MS Windows) that connected to Samba server on the machine that runs Mozilla.


Those are options of my Samba daemon that may be significant:

client code page = 852
character set = ISO8859-2


Here is what characters the filename actually consists of:

[olo@tuxia public]$ ls tel*
telefony_r
(Reporter)

Comment 14

17 years ago
Damn, bugzilla doesn't like that character either...

Resending.

Here is what characters the filename actually consists of:

[olo@tuxia public]$ ls tel*
telefony_r?nych_ludzi.txt
[olo@tuxia public]$ ls tel* | hexdump   
0000000 6574 656c 6f66 796e 725f bff3 796e 6863
0000010 6c5f 6475 697a 742e 7478 000a          
000001b
[olo@tuxia public]$ ls tel* | hexdump -c
0000000   t   e   l   e   f   o   n   y   _   r 363 277   n   y   c   h
0000010   _   l   u   d   z   i   .   t   x   t  \n                    
000001b
(Assignee)

Comment 15

17 years ago
re: #12
type "locale -a", system should list all installed locale. 
type "setenv LANG pl_PL.UTF-8", this will set the locale. 

I tried this with a build I pulled last Thursday, but I could not 
see any problem. Yes, the file name is displayed with 2 question 
marks, but that is understandable. Those 2 characters was encoded in 
8859-2, but the locale's encoding is utf-8. (My Linux system is RedHat 7.2).
(Reporter)

Comment 16

17 years ago
I still can reproduce it with linux trunk build 2002011606.
Crashes as usual, talkback report TB1735851W.

My system is a Mandrake Linux 8.1, currently running with 2.4.17 kernel.
Created attachment 65401 [details]
full stack trace from debug build
Created attachment 65402 [details]
full backtrace from debug build

oops, wrong mime type
Attachment #65401 - Attachment is obsolete: true
dougt -- nsIFile::GetUnicodeLeafName is returning null here.  Should this be
your bug?

Comment 20

17 years ago
are you treating the unicode string as ascii?
I'm doing:

nsXPIDLString unicodeLeafName;
file->GetUnicodeLeafName(getter_Copies(unicodeLeafName));

at this point. unicodeLeafName.get() returns a null PRUnichar*.

Comment 22

17 years ago
Frank added that code.  
ftang, any idea why GetUnicodeLeafName would return null?
Roy, ftang said you might be able to figure out what's going on here...
Assignee: bryner → yokoyama

Comment 25

17 years ago
give to shanjian, this is a linux bug
Assignee: yokoyama → shanjian
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.2

Updated

17 years ago
Keywords: crash
(Reporter)

Comment 26

17 years ago
I can't reproduce this bug with the latest build - it has gone away.
Marking FIXED.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
(Reporter)

Comment 27

17 years ago
BTW it has been fixed somewhere between build 2002-03-28 (crashes) and
2002-04-11 (doesn't crash, but also doesn't display filename).
Tha latest build gracefully shows the filename, invalid characters are shown
with whatever representation in the active charset would be appropriate.
You need to log in before you can comment on or make changes to this bug.