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

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Aleksander Adamowski]

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 ()

Comment 1

[Aleksander Adamowski]

Attachment: testcase

Comment 2

[Aleksander Adamowski]

Attachment: session with gdb (including backtrace)

Comment 3

[Aleksander Adamowski]

correcting a typo in summary...

Comment 4

[Doug Turner (:dougt)]

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?

Comment 5

[Aleksander Adamowski]

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.

Comment 6

[Aleksander Adamowski]

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

Comment 7

[Aleksander Adamowski]

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

[Doug Turner (:dougt)]

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() 

Comment 9

[Aleksander Adamowski]

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.

Comment 10

[Aleksander Adamowski]

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

Comment 11

[Aleksander Adamowski]

(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.

Comment 12

[Brian Ryner (not reading)]

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!

Comment 13

[Aleksander Adamowski]

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

Comment 14

[Aleksander Adamowski]

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

Comment 15

[Shanjian Li]

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

Comment 16

[Aleksander Adamowski]

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.

Comment 17

[Brian Ryner (not reading)]

Attachment: full stack trace from debug build

Comment 18

[Brian Ryner (not reading)]

Attachment: full backtrace from debug build

oops, wrong mime type

Comment 19

[Brian Ryner (not reading)]

dougt -- nsIFile::GetUnicodeLeafName is returning null here.  Should this be
your bug?

Comment 20

[Doug Turner (:dougt)]

are you treating the unicode string as ascii?

Comment 21

[Brian Ryner (not reading)]

I'm doing:

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

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

Comment 22

[Doug Turner (:dougt)]

Frank added that code.  

Comment 23

[Brian Ryner (not reading)]

ftang, any idea why GetUnicodeLeafName would return null?

Comment 24

[Brian Ryner (not reading)]

Roy, ftang said you might be able to figure out what's going on here...

Comment 25

[Frank Tang]

give to shanjian, this is a linux bug

Comment 26

[Aleksander Adamowski]

I can't reproduce this bug with the latest build - it has gone away.
Marking FIXED.

Comment 27

[Aleksander Adamowski]

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.