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 ()
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
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?
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.
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...
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
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
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.
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).
(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!
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
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
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).
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 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?
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*.
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
give to shanjian, this is a linux bug
Assignee: yokoyama → shanjian
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.2
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
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.